[Shift2] Dead?

[simplezz]

But if the drive is blank ^ then it won't detect an EFI table because the disk won't have one :/.

hmm, good point. I'm not too sure on that one. I found a small tidbit here:

Access to UEFI Runtime services is provided by "efivars" kernel module which is enabled through the CONFIG_EFI_VAR=m kernel config option. This module once loaded exposes the variables under the directory /sys/firmware/efi/vars. One way to check whether the system has booted in UEFI boot mode is to load the "efivars" kernel module and check for the existence of /sys/firmware/efi/vars directory with contents similar to :

So in theory, one could just do:

modprobe efivars && ls /sys/firmware/efi/vars

[n_K]

I'll give that a go later on esxi and see if it works!

[threesixtyflip]

Any news n_K?

We could always just have a question when its launched, are you UEFI or BIOS :p

Would be awful, but would work :D

[n_K]

Too busy with uni to work on it atm.

[threesixtyflip]

Too busy with uni to work on it atm.

Thats cool :)

[simplezz]

I've rewritten most of the code I was using to play around with reading partition tables so that it's more structured. The figures seem to be coming out right now, on my system at least. It's still somewhat buggy and I haven't tested it thoroughly, but if you want to play around with it, I've attached the code.

disks.zip

The program needs to be run as a super user ( sudo ) if you wish to see the 'used' statistic of unmounted file systems. It temporarily mounts them if they aren't already mounted and registered in /etc/mtab.

Some outstanding problems:

1. The gtk widget I created for visualising the disk layout isn't perfect. Specifically, I need to fix the way it allocates space for each volume. Currently it runs out of space quickly. Perhaps I need to loop through the volumes and adjust the spacing before I do the actual rendering, but I'll try and fix that later.

2. I had a real hassle trying to programmatically mount the block device file systems so I could get statistics via statvfs (). Specifically, the mount () function requires file system specific esoteric arguments that I just couldn't get to work ( as of yet ), so for now I'm just calling out to the shell's mount command. It's not ideal, but it works.

Again, there are bugs, and the code is messy in parts. To compile you'll need your distro's gtk3 dev package. On arch, it's just extra/gtk3. On Ubuntu/Mint/others it's probably libgtk-3-dev or something like similar. Obviously, you'll need gcc/pkg-config installed as normal.

When I have more time, I'll fix the outstanding bugs.

[n_K]

That looks beautiful! Nice work! :D

Only problem with it is that it needs GTK3, and PHP-GTK is GTK2 only :(

EDIT: Ah you've done it as C... Guess we could run that seperately somehow and output a command list the installer could read?

Edited October 14, 2012 by n_K

[simplezz]

That looks beautiful! Nice work! :D

Only problem with it is that it needs GTK3, and PHP-GTK is GTK2 only :(

Thanks. It's a start at least.

As far as gtk goes, it's easy enough to convert it to gtk2. The only major changes needed to convert it revolve around:

PRIVATE void
disk_layout_class_init ( DiskLayoutClass *in )
{
	GtkWidgetClass *base;

	base = GTK_WIDGET_CLASS ( in );
	base->draw  = disk_layout_draw;

	g_type_class_add_private ( in, sizeof ( disk_info ) );
}

Just change the 'base->draw' override to 'base->expose_event'. There are a few other minor changes like retrieving the widget's allocation, and container v/h boxes.

[simplezz]

EDIT: Ah you've done it as C... Guess we could run that seperately somehow and output a command list the installer could read?

The code is quite modular. You could stick some of it ( block_dev.c, partition.c, fs.c ) into a shared library and call it from php perhaps. Or as you say, run it separately. The code I have here already prints the tables to stdout, so I suppose you could redirect that or parse it in some way.

The widget could easily be implemented in php I would think.

Edit: The same information can probably be obtained from /proc/partitions and /sys/block if you prefer the directory iteration / parsing static text files route. I opted for reading the partition tables directly from the block devices just to see if I could do it ;). I get the list of block devices from /sys/block myself.

[simplezz]

I've fixed the widget problem (mostly). As I thought, it was as simple as reserving space for each volume:

PRIVATE int
disk_layout_calc_reserved ( PartitionTable * t )
{
	Partition *p;
	int	   res = 0;

	p = NULL;
	while ( NULL != ( p = LIST_ITER ( t, p ) ) )
		res += VOLUME_LINE_WIDTH + VOLUME_SPACING;

	res += VOLUME_SPACING;
	return res;	
} 
...
PRIVATE gboolean
disk_layout_draw ( GtkWidget *layout, cairo_t *cr )
...
geometry.width -= disk_layout_calc_reserved ( info->table ); 

There might be an easier or better way of doing it without pre-calculating space to reserve, but I haven't thought of one yet, so this will do for now.

[threesixtyflip]

Wow, how do you guys learn all this stuff?

[DGMurdockIII]

OK so I just quickly added the PHP-GD code to the installer code (after compiling php-gd twice!) and made it change the first image to see if it'd work. It did! So then I got it working via a GDKPixBuf using a GD image instead of having to save the file at all, so it's pretty nifty!

look in to the https://gitorious.org/chakra/tribe it the Chakra installer witch is a arch based distro witch you might be able to make use of

[n_K]

look in to the https://gitorious.org/chakra/tribe it the Chakra installer witch is a arch based distro witch you might be able to make use of

We already looked at that, it's QT/KDE based not gnome so not applicable.

[DGMurdockIII]

b

We already looked at that, it's QT/KDE based not gnome so not applicable.

im just saying use the installer code and use gnome if you want

[n_K]

b

im just saying use the installer code and use gnome if you want

No, it's been discussed and it'd be pointless, might as well just use their distro if that's all we were doing. And having GTK3 and QT on an installer ISO would make it massive for no real reason and confuse people.

[Haggis Veteran]

So how far are we actually into the install?

[n_K]

Installer's still at the same progress as it was, don't really have the time to work on it much now plus the update has borked this arch OS so I can't startx to run things on the VM remotely for testing so until arch bucks up and I get more free time it's completely stale.

[DGMurdockIII]

what about this https://github.com/faidoc/Cnchi

[n_K]

what about this https://github.com/faidoc/Cnchi

Yeah you're missing the point, why just stick that on arch, make an ISO and distribute it? There's nothing to be learnt by doing that, anyone can do it. Making a GUI etc. is all experience and gets you up to scratch with the base of the OS.

[DGMurdockIII]

if you really want to make a arch based distro why not work just work with antergos http://www.antergos.com/

[Growled Member]

I think this is dead. 

[DGMurdockIII]

work with antergos http://www.antergos.com/ why not