Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[RFC] Rewriting sade(8)

9 views
Skip to first unread message

Andrey V. Elsukov

unread,
Apr 7, 2010, 12:35:51 PM4/7/10
to freebsd...@freebsd.org, freebs...@freebsd.org
Hi, All.

Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-)
Today i have progress and you can see some screenshoots here:
http://butcher.heavennet.ru/sade/

What is done:
1. It's fully rewritten, but yes, i reuse some code from old sade.
2. I wrote small framework "customdlg" for creating custom dialogs (not yet fully finished, but works).
3. Now sade use libgeom for searching providers and it can use:
{"DISK", "disk device"},
{"MD", "memory backed virtual disk"},
{"ZFS::ZVOL", "ZFS volume"},
{"MIRROR", "GEOM based mirror (RAID1)"},
{"STRIPE", "GEOM based stripe (RAID0)"},
{"RAID3", "GEOM based RAID3 array"},
{"CONCAT", "GEOM based concatenated disk"},
{"ELI", "GEOM based encrypted disk"},
{"JOURNAL", "GEOM based journalled disk"},
{"MULTIPATH", "GEOM based disk with multiple path"}
4. Access to partitions based on geom_part.so library. I made some changes in geom_part.c and
sent it to Marcel, but currently didn't receive answer. Any way if these changes is not acceptable
i can rewrite it for using libgeom(3) only.
5. Undo/Commit features are based on internal implementation of geom class PART. I found there
two bugs:
http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html
6. All "device" related code can be placed in shared library and in future can be reused in another
frontend...
7. New Partition Editor:
* partitions list now scrollable;
* all operations based on geom_part.so and similar to gpart(8);
* opening partition editor on empty provider opens new "Selech Partitioning Scheme" dialog
and create selected scheme;
* new add slice dialog;
* deleting slice from empty table destroys scheme;

Todo:
1. Refine customdlg.
2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so.
3. "Set Type and Label" dialog.
4. Better wording needed for messages and help. My english is bad :(
------
Missing functions:
Creating filesystem and save them into /etc/fstab.

What new can be added:
1. Creating ZFS pools and datasets.
2. Creating GEOM-based raids.

Any comments are welcome.
--
WBR, Andrey V. Elsukov

Randi Harper

unread,
Apr 7, 2010, 1:49:35 PM4/7/10
to Andrey V. Elsukov, freebsd...@freebsd.org, Devin Teske, freebs...@freebsd.org
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
>

Wow. This is awesome. patches? :D

I've been working on moving sysinstall from libdisk to libgeom, but
unfortunately it's a bit more complicated (redoing the way we detect
devices while I'm at it). I've done a lot of the heavy lifting code,
but I haven't even started on the GUI parts yet. I'd love to see how
someone else tackled doing this. I'm particularly interested in #5 &
#7. :)

Generally, we try to keep sysinstall's disk tools and sade in sync, so
I would like to work with you on this and see what we can come up
with. I'm not entirely sure if #2 is a viable option since we already
have functions in sysinstall that handle generating dialog boxes with
libdialog, but if it's an improvement on what's existing, bring it on.

CC:ing Devin Teske on this thread, as he's displayed interest in
helping as well. My goal is to get all this in for 8.2, so there's
quite a bit to work out in a short period of time.

-- randi

Alex Kozlov

unread,
Apr 7, 2010, 2:13:36 PM4/7/10
to Randi Harper, Andrey V. Elsukov, freebsd...@freebsd.org, Devin Teske, freebs...@freebsd.org
I have half-finished code that uses /sbin/gpart instead of libdisk or libgeom.
Half-finished, because it initialy used /sbin/{fidsk,bsdlabel,gpt}
So now I plan to finish the conversion to gpart and add work with gpt to
mbr and bsdlable handling.

> CC:ing Devin Teske on this thread, as he's displayed interest in
> helping as well. My goal is to get all this in for 8.2, so there's
> quite a bit to work out in a short period of time.
>
> -- randi


--
Adios

Andrey V. Elsukov

unread,
Apr 8, 2010, 1:25:47 AM4/8/10
to Randi Harper, freebsd...@freebsd.org, Devin Teske, freebs...@freebsd.org
On 07.04.2010 21:49, Randi Harper wrote:
> Wow. This is awesome. patches? :D

:)
I'm not ready yet to publish code. I planned to announce this RFC
a bit later, when code will be finished. But Konstantin (kib@) suggested
do it before finishing.

> I've been working on moving sysinstall from libdisk to libgeom, but
> unfortunately it's a bit more complicated (redoing the way we detect
> devices while I'm at it). I've done a lot of the heavy lifting code,
> but I haven't even started on the GUI parts yet. I'd love to see how
> someone else tackled doing this. I'm particularly interested in #5&
> #7. :)

Initially i wanted to only modify current sade's code to move it from
libdisk to libgeom. But after several attempts i decided that it will be
easier to rewrite it :)

> Generally, we try to keep sysinstall's disk tools and sade in sync, so
> I would like to work with you on this and see what we can come up
> with. I'm not entirely sure if #2 is a viable option since we already
> have functions in sysinstall that handle generating dialog boxes with
> libdialog, but if it's an improvement on what's existing, bring it on.

Yes, I looked at this code in sysinstall and in libdialog. Also I looked
to another console UI libs. The main problem of using external libraries
is that not so easy import them into base system.

libdialog have several problemls too, imho.
1. Custom dialogs based on ComposeObj are ugly :)
2. It supports *only* single-byte characters. Initially I wanted to
write code with message catalogs support. But after several tests
I leaved this idea. Also it seems there is no catgets analog for
wide characters.

Bruce Cran

unread,
Apr 8, 2010, 2:27:20 AM4/8/10
to freebsd...@freebsd.org, Andrey V. Elsukov, Devin Teske, Randi Harper, freebs...@freebsd.org
On Thursday 08 April 2010 06:25:47 Andrey V. Elsukov wrote:

> I'm not ready yet to publish code. I planned to announce this RFC
> a bit later, when code will be finished. But Konstantin (kib@) suggested
> do it before finishing.

That's a shame. As long as the source isn't available it's of little interest
to me.

For anyone who wants to see the bits of code I've got so far, I've created a
Google Code project at http://code.google.com/p/gcpart/ . I'm currently trying
to figure out how to get the partitioning scheme out of the XML tree, which is
why there's no geom code there yet. As soon as I do so, I'll start checking
in my effort at the new partitioning application.

--
Bruce Cran

Andrey V. Elsukov

unread,
Apr 8, 2010, 2:51:08 AM4/8/10
to Bruce Cran, freebsd...@freebsd.org, Devin Teske, Randi Harper, freebs...@freebsd.org
On 08.04.2010 10:27, Bruce Cran wrote:
> That's a shame. As long as the source isn't available it's of little interest
> to me.
>
> For anyone who wants to see the bits of code I've got so far, I've created a
> Google Code project at http://code.google.com/p/gcpart/ . I'm currently trying
> to figure out how to get the partitioning scheme out of the XML tree, which is
> why there's no geom code there yet. As soon as I do so, I'll start checking
> in my effort at the new partitioning application.

I just thinking about future of my project. It seems there are several people
who worked on the same before. And I have not finished yet only few things from
initially planned. After that i can remove any unused code, write some comments
and publish it somewhere in perforce.
Also at this time code depends on changes which i made in geom_part.so and which
are not yet commited into base system.
After code review there can be several ways to go. And I have an interest which way
will be for me :)

Randi Harper

unread,
Apr 8, 2010, 3:27:31 AM4/8/10
to Andrey V. Elsukov, adr...@freebsd.org, freebsd...@freebsd.org, Devin Teske, freebs...@freebsd.org
2010/4/7 Andrey V. Elsukov <bu7...@yandex.ru>:

It's great that you want to work on this, but there are other people
working in the same area, so keeping your code to yourself for too
long makes it very likely that it will never get used.

-- randi

Andrey V. Elsukov

unread,
Apr 8, 2010, 4:09:39 AM4/8/10
to Randi Harper, adr...@freebsd.org, freebsd...@freebsd.org, Devin Teske, freebs...@freebsd.org
On 08.04.2010 11:27, Randi Harper wrote:
> It's great that you want to work on this, but there are other people
> working in the same area, so keeping your code to yourself for too
> long makes it very likely that it will never get used.

Ok. I put the code here:
http://butcher.heavennet.ru/sade/sade-20100408.tgz

Alexander Leidinger

unread,
Apr 8, 2010, 4:38:09 AM4/8/10
to Andrey V. Elsukov, Bruce Cran, De...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org
Quoting "Andrey V. Elsukov" <bu7...@yandex.ru> (from Thu, 08 Apr 2010
10:51:08 +0400):

> On 08.04.2010 10:27, Bruce Cran wrote:
>> That's a shame. As long as the source isn't available it's of
>> little interest
>> to me.
>>
>> For anyone who wants to see the bits of code I've got so far, I've created a
>> Google Code project at http://code.google.com/p/gcpart/ . I'm
>> currently trying
>> to figure out how to get the partitioning scheme out of the XML
>> tree, which is
>> why there's no geom code there yet. As soon as I do so, I'll start checking
>> in my effort at the new partitioning application.
>
> I just thinking about future of my project. It seems there are several people
> who worked on the same before. And I have not finished yet only few
> things from
> initially planned. After that i can remove any unused code, write
> some comments
> and publish it somewhere in perforce.

Please consider using SVN instead. A lot more users will be able to
check out from there.

> Also at this time code depends on changes which i made in
> geom_part.so and which
> are not yet commited into base system.
> After code review there can be several ways to go. And I have an
> interest which way
> will be for me :)

It looks like other people had a look at sysinstall, not at sade. As
sysinstall is supposed to be used at installation time, and the intent
for sade was to offer the functionality (or more) of the part of
sysinstall which is useful after installation (and to prevent admins
from using sysinstall after the installation to prevent some unwanted
foot-shooting), I do not think that we need to think about a strong
lock between sysinstall and sade.

If you can enhance sade beyond what sysinstall is able to do, I would
say go ahead (note: I committed sade).

Bye,
Alexander.

--
Leela: "He's crude and gross and he treats me like a slave."
Fry: "Then dump his one-eyed ass."

http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137

Dag-Erling Smørgrav

unread,
Apr 8, 2010, 5:05:34 AM4/8/10
to Alexander Leidinger, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov, De...@freebsd.org
Alexander Leidinger <Alex...@Leidinger.net> writes:
> Please consider using SVN instead. A lot more users will be able to
> check out from there.

We don't grant non-committers access to the Subversion repo.

> It looks like other people had a look at sysinstall, not at sade. As
> sysinstall is supposed to be used at installation time, and the intent
> for sade was to offer the functionality (or more) of the part of
> sysinstall which is useful after installation (and to prevent admins
> from using sysinstall after the installation to prevent some unwanted
> foot-shooting), I do not think that we need to think about a strong
> lock between sysinstall and sade.

Yes we do. Otherwise we'll just end up back where we are today, where
if you want anything more complicated than a single-disk install you
have to drop into the fixit shell and do it manually before running the
installation procedure. Anythig that sade can do, we want sysinstall to
do as well, and we don't want to implement everything twice.

My suggestion is to add a "sysinstall mode" to sade where it operates
under certain (minor) constraints and reports what it did in a format
that sysinstall can parse, so sysinstall can just fork-exec sade instead
of duplicating the code.

DES
--
Dag-Erling Smørgrav - d...@des.no

Svein Skogen (Listmail Account)

unread,
Apr 8, 2010, 6:19:24 AM4/8/10
to freebsd...@freebsd.org

Wouldn't a setup similar to fetch/libfetch do the trick here? Move most
of the actual "working payload" of sade into a library, and make sade
just a frontend for this? That way poking the sysinstall code to use
sade should be easier, and updates will automagically fix both things?

//Svein

--
--------+-------------------+-------------------------------
/"\ |Svein Skogen | sv...@d80.iso100.no
\ / |Solberg Østli 9 | PGP Key: 0xE5E76831
X |2020 Skedsmokorset | sv...@jernhuset.no
/ \ |Norway | PGP Key: 0xCE96CE13
| | sv...@stillbilde.net
ascii | | PGP Key: 0x58CD33B6
ribbon |System Admin | svein-l...@stillbilde.net
Campaign|stillbilde.net | PGP Key: 0x22D494A4
+-------------------+-------------------------------
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle: SS16503-RIPE
--------+-------------------+-------------------------------
If you really are in a hurry, mail me at
svein-...@stillbilde.net
This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
------------------------------------------------------------
Picture Gallery:
https://gallery.stillbilde.net/v/svein/
------------------------------------------------------------

signature.asc

Alexander Leidinger

unread,
Apr 8, 2010, 6:15:00 AM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov, De...@freebsd.org
Quoting Dag-Erling Smørgrav <d...@des.no> (from Thu, 08 Apr 2010
11:05:34 +0200):

> Alexander Leidinger <Alex...@Leidinger.net> writes:
>> Please consider using SVN instead. A lot more users will be able to
>> check out from there.
>
> We don't grant non-committers access to the Subversion repo.

Ooops... seems I misremembered his status. Somehow I associate him
with something FreeBSD related. Andrey, did you participate in a GSoC?

>> It looks like other people had a look at sysinstall, not at sade. As
>> sysinstall is supposed to be used at installation time, and the intent
>> for sade was to offer the functionality (or more) of the part of
>> sysinstall which is useful after installation (and to prevent admins
>> from using sysinstall after the installation to prevent some unwanted
>> foot-shooting), I do not think that we need to think about a strong
>> lock between sysinstall and sade.
>
> Yes we do. Otherwise we'll just end up back where we are today, where
> if you want anything more complicated than a single-disk install you
> have to drop into the fixit shell and do it manually before running the
> installation procedure. Anythig that sade can do, we want sysinstall to
> do as well, and we don't want to implement everything twice.

From the man page:
---snip---
NOTES
The sade utility aims to provide a handy tool for disk management tasks
on an already installed system.
---snip---

Disk management tasks contains stuff which exceeds what sysinstall
needs to provide. One possible extension is to display content from
/etc/dumpdates along with partitions (would be helpful if someone uses
dump to make backups and wants to delete a partition, but only if
there is a recent backup available).

> My suggestion is to add a "sysinstall mode" to sade where it operates
> under certain (minor) constraints and reports what it did in a format
> that sysinstall can parse, so sysinstall can just fork-exec sade instead
> of duplicating the code.

I think this is more complicated than to refactor the interesting part
into a backend with an API which both tools can use. This would also
allow someone to write a GUI program (e.g. for PC-BSD).

Again, there is no need for a *strong* lock between sysinstall and
sade. Both should provide similar features regarding partition and
slice handling, but they do not need to share exactly the same
interface code.

Bye,
Alexander.

--
Above all else - sky.

Andriy Gapon

unread,
Apr 8, 2010, 6:20:30 AM4/8/10
to Dag-Erling Smørgrav, Andrey V. Elsukov, Alexander Leidinger, freebsd...@freebsd.org, freebs...@freebsd.org
on 08/04/2010 12:05 Dag-Erling Smørgrav said the following:

> Alexander Leidinger <Alex...@Leidinger.net> writes:
>> Please consider using SVN instead. A lot more users will be able to
>> check out from there.
>
> We don't grant non-committers access to the Subversion repo.

But nothing stops Andrey from creating his own svn/hg/git/etc repo _just_ for his
sade bits. It's easy. This is what I would do even just for my own sake.

--
Andriy Gapon

Andrey V. Elsukov

unread,
Apr 8, 2010, 6:30:33 AM4/8/10
to Alexander Leidinger, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, De...@freebsd.org, Dag-Erling Smørgrav
On 08.04.2010 14:15, Alexander Leidinger wrote:
>> We don't grant non-committers access to the Subversion repo.
>
> Ooops... seems I misremembered his status. Somehow I associate him with
> something FreeBSD related. Andrey, did you participate in a GSoC?

No, I'm not fit for GSoC.

>> My suggestion is to add a "sysinstall mode" to sade where it operates
>> under certain (minor) constraints and reports what it did in a format
>> that sysinstall can parse, so sysinstall can just fork-exec sade instead
>> of duplicating the code.

I like this idea. Any way i'll try to finish my work myself.

Rui Paulo

unread,
Apr 8, 2010, 6:05:59 AM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, De...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
On 8 Apr 2010, at 10:05, Dag-Erling Sm�rgrav wrote:

> Alexander Leidinger <Alex...@Leidinger.net> writes:
>> Please consider using SVN instead. A lot more users will be able to
>> check out from there.
>
> We don't grant non-committers access to the Subversion repo.

The SVN repo is available to the public via HTTP.

Regards,
--
Rui Paulo

Dag-Erling Smørgrav

unread,
Apr 8, 2010, 7:13:03 AM4/8/10
to Rui Paulo, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
Rui Paulo <rpa...@freebsd.org> writes:

> Dag-Erling Smørgrav <d...@des.no> writes:
> > Alexander Leidinger <Alex...@Leidinger.net> writes:
> > > Please consider using SVN instead. A lot more users will be able
> > > to check out from there.
> > We don't grant non-committers access to the Subversion repo.
> The SVN repo is available to the public via HTTP.

AFAIK, the OP is not a committer, and hence does not have write access.

Dag-Erling Smørgrav

unread,
Apr 8, 2010, 8:01:33 AM4/8/10
to Alexander Leidinger, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov, De...@freebsd.org
Alexander Leidinger <Alex...@Leidinger.net> writes:
> I think this is more complicated than to refactor the interesting part
> into a backend with an API which both tools can use. This would also
> allow someone to write a GUI program (e.g. for PC-BSD).

There have been at least three or four attempts to do this in the past.
One of them was even fully funded by the FreeBSD Foundation. They all
failed.

Alexander Leidinger

unread,
Apr 8, 2010, 9:53:09 AM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov, De...@freebsd.org
Quoting Dag-Erling Smørgrav <d...@des.no> (from Thu, 08 Apr 2010
14:01:33 +0200):

I was told a lot of people tried to make the WITH_CTF part working
without the need to use -DWITH_CTF each time at the command line and
failed. Nevertless I did it. So telling something is not possible
because other people tried and failed is ridiculous. If there is no
proof that it can not be done, I'm sure someone exists who is able to
do it.

I stand by my words and still say that it is less complicated to put
the logic into a backend-lib. If Andrey has problems to do this, I'm
willing to invest some time to mentor him in this regard.

BTW: I do not think you talk about a partition editor, but about the
complete sysinstall. This is a different beast than only the part
which I outlined above. Andrey has already some working stuff which
just needs to be refactored into frontend/backend-lib parts.

Bye,
Alexander.

--
UNIX is many things to many people,
but it's never been everything to anybody.

Rui Paulo

unread,
Apr 8, 2010, 10:08:35 AM4/8/10
to John Baldwin, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov, Dag-Erling Smørgrav, Alexander Leidinger
On 8 Apr 2010, at 13:49, John Baldwin wrote:

> Actually, I would rather have sysinstall just invoke sade to do the disk
> related stuff. Also, I think sysinstall should allow for a "back-door" mode
> where a user can setup partitions however they like and mount them at /mnt and
> then let sysinstall use the setup the user created. This will allow users to
> setup more complex setups that sysinstall/sade do not currently support and
> allow sade to focus on simpler, common usage cases w/o having to handle
> painful edge cases. It would also allow for new modules to be added to sade
> over time w/o requiring it to support every possible disk layout from the
> beginning.

I couldn't agree more.

Regards,
--
Rui Paulo

John Baldwin

unread,
Apr 8, 2010, 8:49:12 AM4/8/10
to freebsd...@freebsd.org, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov, Alexander Leidinger, Dag-Erling Smørgrav
On Thursday 08 April 2010 5:05:34 am Dag-Erling Smørgrav wrote:

Actually, I would rather have sysinstall just invoke sade to do the disk

related stuff. Also, I think sysinstall should allow for a "back-door" mode
where a user can setup partitions however they like and mount them at /mnt and
then let sysinstall use the setup the user created. This will allow users to
setup more complex setups that sysinstall/sade do not currently support and
allow sade to focus on simpler, common usage cases w/o having to handle
painful edge cases. It would also allow for new modules to be added to sade
over time w/o requiring it to support every possible disk layout from the
beginning.

--
John Baldwin

Dag-Erling Smørgrav

unread,
Apr 8, 2010, 10:15:27 AM4/8/10
to Alexander Leidinger, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov, De...@freebsd.org
Alexander Leidinger <Alex...@Leidinger.net> writes:
> Dag-Erling Smørgrav <d...@des.no> writes:
> > There have been at least three or four attempts to do this in the
> > past. One of them was even fully funded by the FreeBSD Foundation.
> > They all failed.
> I was told a lot of people tried to make the WITH_CTF part working
> without the need to use -DWITH_CTF each time at the command line and
> failed. Nevertless I did it. So telling something is not possible
> because other people tried and failed is ridiculous.

It's not ridiculous, it's experience. *Painful* experience over a
period of nearly 15 years.

> BTW: I do not think you talk about a partition editor, but about the
> complete sysinstall.

Yes and no. I'm talking about making the user interface pluggable,
i.e. run the same program (whether sysinstall or sade) with, say, an
ncurses interface on the console and a gtk interface in X.

Debian's package system does this, to a certain extent, but only for
very simple configuration questions - about the same level of
functionality that you get with an HTML form.

Dag-Erling Smørgrav

unread,
Apr 8, 2010, 10:19:48 AM4/8/10
to John Baldwin, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
John Baldwin <j...@freebsd.org> writes:
> Dag-Erling Smørgrav <d...@des.no> writes:
> > My suggestion is to add a "sysinstall mode" to sade where it
> > operates under certain (minor) constraints and reports what it did
> > in a format that sysinstall can parse, so sysinstall can just
> > fork-exec sade instead of duplicating the code.
> Actually, I would rather have sysinstall just invoke sade to do the
> disk related stuff.

...which is exactly what I said - but in the sysinstall case, you may
want to ask some additional questions ("are you sure you want to proceed
without a swap partition?") or place some additional constraints (such
as "don't allow the user to mount something on top of /mnt or /rescue"),
and sysinstall needs to know the outcome.

Alexander Leidinger

unread,
Apr 8, 2010, 10:39:36 AM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov
Quoting Dag-Erling Smørgrav <d...@des.no> (from Thu, 08 Apr 2010
16:15:27 +0200):

> Alexander Leidinger <Alex...@Leidinger.net> writes:
>> Dag-Erling Smørgrav <d...@des.no> writes:
>> > There have been at least three or four attempts to do this in the
>> > past. One of them was even fully funded by the FreeBSD Foundation.
>> > They all failed.
>> I was told a lot of people tried to make the WITH_CTF part working
>> without the need to use -DWITH_CTF each time at the command line and
>> failed. Nevertless I did it. So telling something is not possible
>> because other people tried and failed is ridiculous.
>
> It's not ridiculous, it's experience. *Painful* experience over a
> period of nearly 15 years.
>
>> BTW: I do not think you talk about a partition editor, but about the
>> complete sysinstall.
>
> Yes and no. I'm talking about making the user interface pluggable,
> i.e. run the same program (whether sysinstall or sade) with, say, an
> ncurses interface on the console and a gtk interface in X.

I did not suggest to run the same program and get different
interfaces. My suggestion was to have a backend-lib and a frontend.
The backend containing the "business-logic", and the frontend being
the presentation layer. If you want a GTK GUI, write a new frontend.
In the case of sysinstall and sade, both use some kind of curses
interface, my suggestion was to the lib as they are both 2 different
kind of frontends (two different kinds of point of view regarding the
required functionality).

I was misunderstanding your idea in the beginning, I was understanding
the description of jhb better. It surely is an applicable idea (and an
improvement to what we have currently), but it looks like it is
limiting what we could do with sade (the frontend part, not the
backend part) if it would be decoupled from sysinstall.

Bye,
Alexander.

--
BOFH excuse #144:

Too few computrons available

Dag-Erling Smørgrav

unread,
Apr 8, 2010, 10:50:16 AM4/8/10
to Alexander Leidinger, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov
Alexander Leidinger <Alex...@Leidinger.net> writes:
> I did not suggest to run the same program and get different
> interfaces. My suggestion was to have a backend-lib and a frontend.
> The backend containing the "business-logic", and the frontend being
> the presentation layer.

What you call the presentation layer is actually 80% of the work. What
you call the business logic already exists (libgeom).

Kris Moore

unread,
Apr 8, 2010, 6:53:48 AM4/8/10
to Alexander Leidinger, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Dag-Erling Smørgrav

That's a pretty similar to the approach we've taken with our new backend
in PC-BSD 8.x. The notable exception is that instead
of just a lib, our backend is a complete program (written in sh), which
performs scripted installs, and provides all the functionality
for front-ends to query the system and present data to the end-user.

This has a few advantages, in that the backend can be used stand-alone
for scripted installations and also provide great flexibility
to the front-end developer. They don't need to worry about performing
any of the actual installation logic, they just provide a way
for users to select their installation options, generate a configuration
script, and let the backend run with it.


--
Kris Moore
PC-BSD Software
iXsystems

Marian Hettwer

unread,
Apr 8, 2010, 12:30:54 PM4/8/10
to Kris Moore, Bruce Cran, freebs...@freebsd.org, Dag-Erling Smørgrav, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
On Thu, 08 Apr 2010 10:53:48 +0000, Kris Moore <kr...@pcbsd.org> wrote:

It's not nice to hijack a topic, but this is way to interesting for me, so
I do it anway :)

> This has a few advantages, in that the backend can be used stand-alone
> for scripted installations and also provide great flexibility
> to the front-end developer. They don't need to worry about performing
> any of the actual installation logic, they just provide a way
> for users to select their installation options, generate a configuration

> script, and let the backend run with it.

scripted installation!
Are you able to do a pxeboot, nfsroot and then scripted installation?
Are those scripts portable to FreeBSD or PC-BSD only?
Could you give me a hint where to find them?

TIA,
Marian

Devin Teske

unread,
Apr 8, 2010, 10:51:45 AM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, John Baldwin, freebs...@freebsd.org, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
I too love the idea of "generalizing" (abstracting) the dirty-work to a
set of libraries and leaving the user interface up to the userland
applications. Thusly, an app in /usr/X11R6/bin can use said libraries in
plugging in functionality to an X11 GUI application, meanwhile an app
in /bin or /sbin (presumably, since we're talking about low-level system
utilities) could use the same libraries for plugging the same
functionality into a command-line interface (beit command-driven or
ncurses/libdialog driven).

However, I'm still wondering what that change would mean to our beloved
sysinstall when it comes time to place sysinstall into the mfsroot for
the CD-ROM installer.

Currently, the mfsroot contains very little in the ways of ELF binaries:

-sh, [ (test), arp, boot_crunch, camcontrol, cpio, dhclient, find,
fsck_4.2bsd, fsck_ffs, fsck_ufs, gunzip, gzip, hostname, ifconfig,
minigzip, mount_nfs, newfs, ppp, pwd, rm, route, rtsol, sed, sh,
sysinstall, test, tunefs, usbconfig, and zcat

Every last one of those is (a) statically linked and (b) hard-linked to
one-another (really, they are all hard-links to boot_crunch which is a
by-product of crunchgen(1)).

What might the landscape look like if we move down the road toward
separating the back-end from the front-end?

Presumably though, we could simply put the bits back together, no?
Currently, the following libraries are slurped into the crunchgen
configuration:

-ll, -ledit, -lutil, -lmd, -lcrypt, -lftpio, -lz, -lnetgraph, -ldialog,
-lncurses, -ldisk, -lcam, -lsbuf, -lufs, -ldevinfo, -lbsdxml, -larchive,
-lbz2, -lusb, and -ljail

Which I show to be these files in RELENG_8:

/usr/lib/libl.a
/usr/lib/libedit.a
/usr/lib/libutil.a
/usr/lib/libmd.a
/usr/lib/libcrypt.a
/usr/lib/libftpio.a
/usr/lib/libz.a
/usr/lib/libnetgraph.a
/usr/lib/libdialog.a
/usr/lib/libncurses.a
/usr/lib/libdisk.a
/usr/lib/libcam.a
/usr/lib/libsbuf.a
/usr/lib/libufs.a
/usr/lib/libdevinfo.a
/usr/lib/libbsdxml.a
/usr/lib/libarchive.a
/usr/lib/libbz2.a
/usr/lib/libusb.a
/usr/lib/libjail.a

I think I just answered my own question...

We should have no problem re-incorporating any heretofore developed
libraries (for the back-end functionality) *back into* the crunchgen
(1)'ed binaries.

In fact, if we, say for example, developed /usr/lib/libsysinstall.a
and /usr/lib/libsade.a , we could then simply just patch
`/usr/src/release/i386/boot_crunch.conf' in the following manner:

[dteske@push800 /usr/src/release/i386]$ diff -u boot_crunch.conf{.bak,}
--- boot_crunch.conf.bak 2010-04-08 07:10:49.000000000 -0700
+++ boot_crunch.conf 2010-04-08 07:10:27.000000000 -0700
@@ -46,3 +46,4 @@
libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph
libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo
libs -lbsdxml -larchive -lbz2 -lusb -ljail
+libs -lsysinstall -lsade

Assuming of course that `release' (and intrinsically `buildworld') is
made to generate the libraries
at /R/stage/trees/base/usr/lib/libsysinstall.a
and /R/stage/trees/base/usr/lib/libsade.a (and respectively for
`buildworld', /usr/obj/usr/src/tmp/usr/lib/libsysinstall.a
and /usr/obj/usr/src/tmp/usr/lib/libsade.a).

So, I guess my fears of "mucking up" the install environment are
unfounded.

All-in-all, I'm right there with y'all on the idea of separating the
front-end from the back-end. It needs to be done (and will open up a
flurry of new installer interfaces and utilities that require low-end
stuff usually own made-available by sysinstall internals).
--
Devin

Cheers,
Devin Teske

-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin...@fisglobal.com

-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.

-> END TRANSMISSION <-

Kris Moore

unread,
Apr 8, 2010, 8:48:57 AM4/8/10
to Marian Hettwer, Bruce Cran, freebs...@freebsd.org, Dag-Erling Smørgrav, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
On 04/08/2010 16:30, Marian Hettwer wrote:
> On Thu, 08 Apr 2010 10:53:48 +0000, Kris Moore<kr...@pcbsd.org> wrote:
>
> It's not nice to hijack a topic, but this is way to interesting for me, so
> I do it anway :)
>
:) I didn't mean to hijack either, was trying to discuss advantage of
having backend
as a executable vs a library which can't be used standalone without
front-end.
This would in effect lock you completely into front-end logic, which may
not meet
a users specific needs, even though backend can do what user wants.

>> This has a few advantages, in that the backend can be used stand-alone
>> for scripted installations and also provide great flexibility
>> to the front-end developer. They don't need to worry about performing
>> any of the actual installation logic, they just provide a way
>> for users to select their installation options, generate a configuration
>>
>
>> script, and let the backend run with it.
>>
> scripted installation!
> Are you able to do a pxeboot, nfsroot and then scripted installation?
> Are those scripts portable to FreeBSD or PC-BSD only?
> Could you give me a hint where to find them?
>
> TIA,
> Marian
>

Correct, every install it does is a fully-scripted installation, and
it can be used with pxeboot, or in a custom mfsroot image easily.
Supports ZFS, glabel, gmirror, geli, GPT, gpart, vanilla FreeBSD
installs, etc.

http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall

Checkout examples/README for all the gory details of config-file
generation.

One caveat, the version in trunk is being very actively worked on by
myself at the
moment to prepare for 8.1, needs more docs, etc ;)

Devin Teske

unread,
Apr 8, 2010, 10:24:27 AM4/8/10
to Rui Paulo, Bruce Cran, John Baldwin, freebsd...@freebsd.org, freebs...@freebsd.org, Randi Harper, Andrey V. Elsukov, Dag-Erling Smørgrav, Alexander Leidinger
(( wishing that I hadn't un-CC'd the group on earlier e-mails ))

Some concerns that I have with separating the code into a back-end
versus front-end...

1. Is it currently the idea that -- when it comes down to the crunchgen
stuff -- we are going to re-work the code that generates the non-shared
binaries for mfsroot? or move away from the crunchgen/mfsroot paradigm?

2. If moving away from crunchgen/mfsroot, ... are we effectively making
the statement that we no longer "support" installing FreeBSD on your
floppy-enabled kitchen toaster? I'm not saying that there's an
overwhelming need to retain the ability to install FreeBSD via
floppy, ... but it uber-legacy support is something to be proud-of (just
as lack-thereof could perhaps be something to be ashamed of -- I can
fall into either camp channeling visions of Steve-Jobs-style mac-like
shunning of the floppy drive or even Bill Gates almost sickening legacy-
support of DOS).

3. We could abandon chrunchgen/mfsroot and simply load up all the back-
end bits with the front-end bits for sysinstall to function in the
installer environment ... but my quarrel is ... will it still fit on a
floppy? if not, are we prepared to deprecate that? otherwise, does
anyone care that the installer environment will be changing from a
collection of staticallly-linked binaries to a "mess" ?

I actually have a really nifty idea for deprecating mfsroot... and
that's to start using syslinux as the boot-loader (which as of version
3.84 supports booting *.iso files). We're doing that in our company
now... we have a CD-ROM that boots SYSLINUX and displays a menu with
many options (among them "FreeBSD"). Selecting "FreeBSD" from the menu
uses SYSLINUX's "memdisk" module to then boot `mdroot.iso' which
essentially an `mfsroot'. The benefit here is that the `mdroot.iso' can
be built cross-platform (matters not if you download our CVS tree to a
Linux box or FreeBSD box... as long as you have `mkisofs' you can
"compile" the disc and all incumbent file systems).

The further beauty of this method is that the resultant mdroot.iso can
be large (currently 14MB in our company ... but that's only because it
contains two monolithic custom kernels which -- because we have a custom
boot loader that allows us to cycle through any number of kernels at
boot time to select the proper one for the hardware in question).
--
Devin

Devin Teske

unread,
Apr 8, 2010, 1:01:37 PM4/8/10
to Kris Moore, Bruce Cran, freebs...@freebsd.org, Dag-Erling Smørgrav, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger, Marian Hettwer
Randi and I were discussion the possibility of having sysinstall
"remember" what you did and then able to write out a suitable
`install.cfg' file that could be subsequently used to perform a human-
less automated install with the same settings.

To expand a little on that...

I'd like to draw a similarity to AppleScript. If you are familiar with
AppleScript, you know that one can launch on Macintoshes (going back as
far as Mac OS 7.0.1) an application known as the "Script Editor" which
had a "Record" button in the [then] top-left corner of the window. After
clicking that "Record" button, the system then recorded what you did
(including in the Desktop [Finder] and other 3rd-party programs) and
saved a series of scripted commands which could simply be "Run" (or
optionally saved into an executable script) to reproduce everything you
did at-once.

The way that this worked was by way of the developer "plugging in"
specific resources (if you're familiar with the ol' days, you'll
undoubtedly remember ResEdit -- specifically, a developer would add an
'aete' resource to the RSRC fork of the HFS file structure (among
others). Then, when a scriptable-action was performed within the
application, rather than calling some internally obscure sub-routine to
perform the task, the developer would have the application actually send
an AppleScript event to the MacOS which then sent it back to the
application. Therefore, when the ScriptEditor is "recording", what it
records is the events being passed from the application to itself as you
go about clicking, dragging and typing things.

It is in this manner that I think we would be best served in
contemplating a "self-scripting" engine.

That is to say, that -- altogether now -- we:

a. separate the GUI front-end from the actual tasks that need to be
performed (back-end; for example, tasks to partition disks, perform
newfs, etc. etc.)

b. have either all commands in the library pass through a "dispatcher"
or only export a single dispatcher function from the library (requiring
all "commands" to pass through this single function)

Then it would then (I perceive) perhaps become a trivial task to have
the dispatcher "record" the events.

Another benefit of this would be that it wouldn't matter whom or what
performed anything at all... there would be a mechanism for recording
what was done regardless. And thus, we would usher in the age of being
even the lay user being able to script the installer to do his/her
bidding.

No?
--
Devin

Garrett Cooper

unread,
Apr 8, 2010, 2:03:37 PM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
2010/4/8 Dag-Erling Smørgrav <d...@des.no>:

If the user shoots him or herself in the foot, that's their own
problem. They should at least read hier(7) or ask a question on
questions@ beforehand. As long as the auto-partitioner is correct,
it's fine. Complicating the tool with a lot of unnecessary criteria
will just produce unnecessary bloat.
Thanks,
-Garrett

Dag-Erling Smørgrav

unread,
Apr 8, 2010, 2:27:03 PM4/8/10
to Garrett Cooper, Bruce Cran, John Baldwin, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
Garrett Cooper <yane...@gmail.com> writes:
> If the user shoots him or herself in the foot, that's their own
> problem.

That kind of attitude is why people choose Linux over FreeBSD...

Garrett Cooper

unread,
Apr 8, 2010, 2:15:36 PM4/8/10
to Devin Teske, Bruce Cran, freebs...@freebsd.org, Alexander Leidinger, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Dag-Erling Smørgrav, Marian Hettwer, Kris Moore
On Thu, Apr 8, 2010 at 10:01 AM, Devin Teske <dte...@vicor.com> wrote:
> Randi and I were discussion the possibility of having sysinstall
> "remember" what you did and then able to write out a suitable
> `install.cfg' file that could be subsequently used to perform a human-
> less automated install with the same settings.

[...]

1. Please don't top post :).
2. install.cfg is just a hacky / non-style(9) compliant way of
specifying how to do an install. If you could separate out sysinstall
into separate utilities and have each of the pieces execute as shell
commands with predefined variables at install, you'll be lightyears
ahead of where sysinstall is today.
3. sysinstall(8) does a lot of crud that it shouldn't do for all
systems. Powerusers won't use sysinstall because does too much crap;
all of the items that sysinstall does behind the scenes to get a
working system should be properly documented in a doc article.

Thanks,
-Garrett

Garrett Cooper

unread,
Apr 8, 2010, 3:31:51 PM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, John Baldwin, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
2010/4/8 Dag-Erling Smørgrav <d...@des.no>:

> Garrett Cooper <yane...@gmail.com> writes:
>> If the user shoots him or herself in the foot, that's their own
>> problem.
>
> That kind of attitude is why people choose Linux over FreeBSD...

Where do you draw the line though? /media, /libexec, /proc, /sys,
etc? I think it's better to educate users than build in more
complexity to the install application.
Besides, how many people have you heard of that created slices for
/mnt or /rescue lately?
Thanks,
-Garrett

Garrett Cooper

unread,
Apr 8, 2010, 3:35:02 PM4/8/10
to Dag-Erling Smørgrav, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
2010/4/8 Garrett Cooper <yane...@gmail.com>:
> 2010/4/8 Dag-Erling Sm�rgrav <d...@des.no>:

Sorry -- meant partition -_-...
Thanks,
-Garrett

Kris Moore

unread,
Apr 8, 2010, 11:46:00 AM4/8/10
to Garrett Cooper, freebsd...@freebsd.org, freebs...@freebsd.org, Devin Teske, Randi Harper, Andrey V. Elsukov, Dag-Erling Smørgrav, Alexander Leidinger, Marian Hettwer
On 04/08/2010 18:15, Garrett Cooper wrote:
> On Thu, Apr 8, 2010 at 10:01 AM, Devin Teske<dte...@vicor.com> wrote:
>
>> Randi and I were discussion the possibility of having sysinstall
>> "remember" what you did and then able to write out a suitable
>> `install.cfg' file that could be subsequently used to perform a human-
>> less automated install with the same settings.
>>
>

In a sense that's what our back-end / front-end is doing currently.

The program flow works like thus:

Front-end starts, queries all relevant information from back-end, Disks,
Network Cards, etc,
then proceeds to walk the user through the steps gathering enough
information to perform
an installation. This gives front-end control over its own data
gathering logic from the user,
since the way I do something in a QT GUI may not work via command-line
without a mouse
or the other way around.

When we are done gathering information, the front-end writes out an
install.cfg directive
and starts the back-end processing it. The front-end then waits and
displays backend output
to the user in a sane manner, allowing user to watch whats going on.

(example)
http://trac.pcbsd.org/browser/pcbsd/trunk/pc-sysinstall/examples/pcinstall.cfg.zfs

So with this method, its pretty much doing what you describe. Every
install is a scripted
install, and if you want to do unattended installs, you can use the
front-end to generate
all the options you want, copy and/or tweak the resulting config to be
used again later.

If the backend is simply a library and not executable, then you'll end
up needing
scripting support or ways to run one implemented directly in each
front-end, which can get
messy to maintain across curses/gtk/qt/web, etc.

Randi Harper

unread,
Apr 8, 2010, 4:16:55 PM4/8/10
to Garrett Cooper, Bruce Cran, freebs...@freebsd.org, Alexander Leidinger, Devin Teske, freebsd...@freebsd.org, Andrey V. Elsukov, Dag-Erling Smørgrav, Marian Hettwer, Kris Moore
On Thu, Apr 8, 2010 at 11:15 AM, Garrett Cooper <yane...@gmail.com> wrote:

> 2. install.cfg is just a hacky / non-style(9) compliant way of
> specifying how to do an install. If you could separate out sysinstall
> into separate utilities and have each of the pieces execute as shell
> commands with predefined variables at install, you'll be lightyears
> ahead of where sysinstall is today.

What does style(9) have to do with install.cfg? From the header in the
man page, style(9) is a "kernel source file style guide". install.cfg
is a configuration file. It is not source code. install.cfg isn't as
good as it could be, admittedly. Like much of sysinstall, it needs
some work, but I wouldn't call it "hacky". It's readable and fairly
easy to understand.

What you're talking about doing is rewriting all of sysinstall. How
many people have said at some point "I'm going to rewrite sysinstall"
or "I'm going to write a replacement for sysinstall"? How many of
those people were successful? We're working on a plan and tackling one
problem at a time, keeping goals manageable. As a result, sysinstall
is getting more TLC now than it has in a very long time.

> 3. sysinstall(8) does a lot of crud that it shouldn't do for all
> systems. Powerusers won't use sysinstall because does too much crap;
> all of the items that sysinstall does behind the scenes to get a
> working system should be properly documented in a doc article.

I consider myself a poweruser, and I've stuck to using sysinstall. I
just select 'custom'. I know a lot of other powerusers - people that
have been sysadmins for a very long time - that also use sysinstall.
Please don't presume to speak for sysadmins everywhere.

I'm not sure what "crud" you're talking about in specific. There's
some things I'd like to see go away (some of the post-install
configuration bits, how the ports tree is installed). There will be an
epic discussion soon of where we'd all like to see sysinstall go
("away" is not the answer I'm looking for :D), but this is going off
topic of the original thread.

There's a lot of work being done to sysinstall right now by a number
of people. I don't want to further complicate things by pushing what
you're suggesting into the mix. What we're discussing at the moment is
sade/sysinstall specific and affects what happens in the immediate
future, not a laundry list of "this is why sysinstall sucks". File a
PR. Submit patches.

-- randi

Alexander Leidinger

unread,
Apr 9, 2010, 3:24:24 AM4/9/10
to Dag-Erling Smørgrav, Bruce Cran, freebsd...@freebsd.org, freebs...@freebsd.org, Teske, Randi Harper, Andrey V. Elsukov
Quoting Dag-Erling Smørgrav <d...@des.no> (from Thu, 08 Apr 2010
16:50:16 +0200):

That's an oversimplification. There is more code which can be shared.

Bye,
Alexander.

--
I'm RELIGIOUS!! I love a man with a HAIRPIECE!! Equip me with
MISSILES!!

Dag-Erling Smørgrav

unread,
Apr 9, 2010, 5:23:18 AM4/9/10
to Garrett Cooper, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
Garrett Cooper <yane...@gmail.com> writes:
> Dag-Erling Smørgrav <d...@des.no> writes:
> > Garrett Cooper <yane...@gmail.com> writes:
> > > Dag-Erling Smørgrav <d...@des.no> writes:
> > > > [restored relevant context which was removed earlier in the thread]

> > > > ...which is exactly what I said - but in the sysinstall case, you may
> > > > want to ask some additional questions ("are you sure you want to proceed
> > > > without a swap partition?") or place some additional constraints (such
> > > > as "don't allow the user to mount something on top of /mnt or /rescue"),
> > > > and sysinstall needs to know the outcome.
> > > If the user shoots him or herself in the foot, that's their own
> > > problem.
> > That kind of attitude is why people choose Linux over FreeBSD...
> Where do you draw the line though? /media, /libexec, /proc, /sys, etc?
> I think it's better to educate users than build in more complexity to
> the install application.

I draw the line at mounting something - anything - on top of directories
that contain files that are critical to sysinstall's operation. IIRC,
/mnt is where the installation CD is mounted.

In sysinstall mode, sade's role is to 1) make sure that something
sensible is mounted in the location where sysinstall is going to install
the OS, 2) assist the user in making the correct disk, slice, partition
or what-have-you bootable, 3) within reasonable limits, prevent the user
from doing something that will break sysinstall, and 4) optionally allow
the user to prepare additional filesystems that sysinstall doesn't care
about (e.g. /usr/obj), as long as this does not conflict with 3).

I think the easiest way to achieve this is for sysinstall to provide an
empty directory (e.g. /inst) and have sade operate with that directory
as root, so what the user sees is how things will look when the system
reboots after installation; when the user asks sade to create /usr/obj,
sade actually creates /inst/usr/obj.

Last but not least, sade should report what it did to sysinstall -
perhaps in fstab format, since sysinstall needs to populate
(/inst)/etc/fstab anyway.

Paul Wootton

unread,
Apr 9, 2010, 6:42:18 AM4/9/10
to Dag-Erling Smørgrav, Bruce Cran, freebs...@freebsd.org, Alexander Leidinger, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Garrett Cooper
But... If this is a fresh install, then you really have not lost
anything if you making a mistake. If sysinstall / sade is run from a
running system and a mistake is made then you could loose your data, but
as you will need to have su-ed up, how does this differ from typing a
wrong command in?

Just my 2 cents

Paul

Dag-Erling Smørgrav

unread,
Apr 9, 2010, 7:29:12 AM4/9/10
to Paul Wootton, Bruce Cran, freebs...@freebsd.org, Alexander Leidinger, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Garrett Cooper
Paul Wootton <pa...@fletchermoorland.co.uk> writes:
> But... If this is a fresh install, then you really have not lost
> anything if you making a mistake. If sysinstall / sade is run from a
> running system and a mistake is made then you could loose your data,
> but as you will need to have su-ed up, how does this differ from
> typing a wrong command in?

Please, please, go have a cup of coffee, then come back and *read what I
wrote* instead of just making stuff up.

John Baldwin

unread,
Apr 9, 2010, 8:40:54 AM4/9/10
to Dag-Erling Smørgrav, Bruce Cran, freebs...@freebsd.org, Alexander Leidinger, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Garrett Cooper
On Friday 09 April 2010 5:23:18 am Dag-Erling Smørgrav wrote:
> Garrett Cooper <yane...@gmail.com> writes:
> > Dag-Erling Smørgrav <d...@des.no> writes:
> > > Garrett Cooper <yane...@gmail.com> writes:
> > > > Dag-Erling Smørgrav <d...@des.no> writes:
> > > > > [restored relevant context which was removed earlier in the thread]
> > > > > ...which is exactly what I said - but in the sysinstall case, you
may
> > > > > want to ask some additional questions ("are you sure you want to
proceed
> > > > > without a swap partition?") or place some additional constraints
(such
> > > > > as "don't allow the user to mount something on top of /mnt or
/rescue"),
> > > > > and sysinstall needs to know the outcome.
> > > > If the user shoots him or herself in the foot, that's their own
> > > > problem.
> > > That kind of attitude is why people choose Linux over FreeBSD...
> > Where do you draw the line though? /media, /libexec, /proc, /sys, etc?
> > I think it's better to educate users than build in more complexity to
> > the install application.
>
> I draw the line at mounting something - anything - on top of directories
> that contain files that are critical to sysinstall's operation. IIRC,
> /mnt is where the installation CD is mounted.

FYI, the CD is mounted at /dist. sysinstall mounts the new filesystems in
/mnt and then chroots into /mnt before doing the actual install.

--
John Baldwin

Garrett Cooper

unread,
Apr 9, 2010, 2:20:00 PM4/9/10
to Dag-Erling Smørgrav, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
2010/4/9 Dag-Erling Smørgrav <d...@des.no>:

> Garrett Cooper <yane...@gmail.com> writes:
>> Dag-Erling Smørgrav <d...@des.no> writes:
>> > Garrett Cooper <yane...@gmail.com> writes:
>> > > Dag-Erling Smørgrav <d...@des.no> writes:
>> > > > [restored relevant context which was removed earlier in the thread]
>> > > > ...which is exactly what I said - but in the sysinstall case, you may
>> > > > want to ask some additional questions ("are you sure you want to proceed
>> > > > without a swap partition?") or place some additional constraints (such
>> > > > as "don't allow the user to mount something on top of /mnt or /rescue"),
>> > > > and sysinstall needs to know the outcome.
>> > > If the user shoots him or herself in the foot, that's their own
>> > > problem.
>> > That kind of attitude is why people choose Linux over FreeBSD...
>> Where do you draw the line though? /media, /libexec, /proc, /sys, etc?
>> I think it's better to educate users than build in more complexity to
>> the install application.
>
> I draw the line at mounting something - anything - on top of directories
> that contain files that are critical to sysinstall's operation.  IIRC,
> /mnt is where the installation CD is mounted.

Ok... rather than hardcoding this list into sysinstall or sade, it
would be nice if it was in some kind of flexible metadata.

> In sysinstall mode, sade's role is to 1) make sure that something
> sensible is mounted in the location where sysinstall is going to install
> the OS, 2) assist the user in making the correct disk, slice, partition
> or what-have-you bootable,

What is sensible today, may not be sensible for all cases or sensible
tomorrow. For instance, there have been some reports about the `Auto
defaults' in sysinstall completely screwing up the size as the default
was way too low for /, and thus a user shot himself in the foot when
doing a binary upgrade via freebsd-update. This `smart default' needs
to exist as a minimum and maximum defined in some kind of metadata,
and it would definitely help if one knew what the use-case would be
for the machine, but one doesn't know this data from the way that
things have been setup.

> 3) within reasonable limits, prevent the user
> from doing something that will break sysinstall,

Point being, how do you qualify the act of not `break[ing] sysinstall'?

> and 4) optionally allow
> the user to prepare additional filesystems that sysinstall doesn't care
> about (e.g. /usr/obj), as long as this does not conflict with 3).
>
> I think the easiest way to achieve this is for sysinstall to provide an
> empty directory (e.g. /inst) and have sade operate with that directory
> as root, so what the user sees is how things will look when the system
> reboots after installation; when the user asks sade to create /usr/obj,
> sade actually creates /inst/usr/obj.

Now you're making a dangerous assumption that /inst isn't being used
by the end-user for any predefined purpose.

> Last but not least, sade should report what it did to sysinstall -
> perhaps in fstab format, since sysinstall needs to populate
> (/inst)/etc/fstab anyway.

Ok. Or maybe since `we're here' sade needs to be populating
$DESTDIR/etc/fstab, not sysinstall ? Ideally sysinstall should be a
thin wrapper over a number of different utilities which would provide
the code for thinking things together, not doing a bunch of
operations. That way the code itself could be divorced from the
activities it's performing a bit better and people could swap in other
solutions as they feel fit (say the PCBSD QT installer, or the myriad
of different installers available today for FreeBSD in GTK, QT, etc
format).

Thanks,
-Garrett

Andrey V. Elsukov

unread,
Apr 9, 2010, 3:08:12 PM4/9/10
to Garrett Cooper, Bruce Cran, Marcel Moolenaar, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Alexander Leidinger, Dag-Erling Smørgrav
09.04.10, 11:20, "Garrett Cooper" <yane...@gmail.com>:

> Ok. Or maybe since `we're here' sade needs to be populating
> $DESTDIR/etc/fstab, not sysinstall ?

I'm also looking for answer to this question. It seems that all basic operations
with partitions are already implemented. And I think about next steps.

Also I think I should make a dialog for writing bootcode. And there are a bunch of
different bootstrap code which can be used with different schemes. So if anyone
can share own experience I'll be grateful.

MBR:
/boot/mbr - standart boot record (is it needed? Is it not the same which gpart creates?).
/boot/boot0 - boot0 boot manager.
/boot/boot0sio - boot0 boot manager with redirected output ot com1.

GPT:
/boot/pmbr - protective mbr
/boot/gptboot - bootstrap code for booting from GPT, should be installed to freebsd-boot
partition.
/boot/gptzfsboot - bootstrap code for booting from GPT and ZFS, should be installed to
freebsd-boot partition.

/boot/zfsboot - bootstrap code for booting from ZFS from MBR, it seems this bootcode doesn't have
a correct way (e.g `gpart bootcode ...`) to be writed.

What about VTOC8, PC98, APM?

--
WBR, Andrey V. Elsukov

Dag-Erling Smørgrav

unread,
Apr 10, 2010, 12:27:46 PM4/10/10
to Garrett Cooper, Bruce Cran, freebs...@freebsd.org, Teske, Randi Harper, freebsd...@freebsd.org, Andrey V. Elsukov, Alexander Leidinger
Garrett Cooper <yane...@gmail.com> writes:
> Now you're making a dangerous assumption that /inst isn't being used
> by the end-user for any predefined purpose.

No, I'm making the entirely reasonable assumption that *during the
installation process* sysinstall can mount whatever the hell it wants
wherever the hell it wants.

Why is this so hard to understand?

If the user wants to create an /inst filesystem *during installation* it
will be mounted as /inst/inst. If the user runs sade *at a later time*
and creates an /inst filesystem, it will be mounted as /inst.

> Ok. Or maybe since `we're here' sade needs to be populating
> $DESTDIR/etc/fstab, not sysinstall ?

At that time (when sysinstall invokes sade) there is no $DESTDIR/etc -
sysinstall hasn't yet started extracting the base distribution.

0 new messages