Making a localized, educational live-usb version of Netbsd? Possible, and is worth it?

[Ottavio Caruso]

I myself am not a very good Dutch speaker, but I would like to help a
local Linux foundation here in the South of the Netherlands that deals
with the education sector.

They use Linux Mint/Ubuntu/Kubuntu for their demonstration but after
showing them that Netbsd doesn't bite, I am considering the
possibility of assembling a live-usb in Dutch, based on Netbsd,
preloaded with internet/office/educational and language-specific
localized applications, ready to go and to boot from any laptop or
desktop.

Has anybody ever done it?

Is this technically possible and would a newbie like me be able to
assemble anything decent?

Would MaheshaNetBSD or Jibbed a good starting point?

Any other ideas/inputs will be appreciated.


--
Ottavio

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> I myself am not a very good Dutch speaker, but I would like to help a
> local Linux foundation here in the South of the Netherlands that deals
> with the education sector.
>
> They use Linux Mint/Ubuntu/Kubuntu for their demonstration but after
> showing them that Netbsd doesn't bite, I am considering the
> possibility of assembling a live-usb in Dutch, based on Netbsd,
> preloaded with internet/office/educational and language-specific
> localized applications, ready to go and to boot from any laptop or
> desktop.
>
> Has anybody ever done it?
>
> Is this technically possible and would a newbie like me be able to
> assemble anything decent?

It should be possible, but I'm not sure that a newbie can do that.

> Would MaheshaNetBSD or Jibbed a good starting point?

I doubt so.

> Any other ideas/inputs will be appreciated.

I have several ideas and can share them. I can even join this project,
just give me a week to think over it.


--
HE CE3OH...

[Thomas Mueller]

> I myself am not a very good Dutch speaker, but I would like to help a
> local Linux foundation here in the South of the Netherlands that deals
> with the education sector.

> They use Linux Mint/Ubuntu/Kubuntu for their demonstration but after
> showing them that Netbsd doesn't bite, I am considering the
> possibility of assembling a live-usb in Dutch, based on Netbsd,
> preloaded with internet/office/educational and language-specific
> localized applications, ready to go and to boot from any laptop or
> desktop.

> Has anybody ever done it?

> Is this technically possible and would a newbie like me be able to
> assemble anything decent?

> Would MaheshaNetBSD or Jibbed a good starting point?

> Any other ideas/inputs will be appreciated.

> Ottavio

I have installed NetBSD amd64 and i386 to USB sticks for stable branches of 5 and 6, and current, don't plan to update 5.2_STABLE any more, and work more with current than releng-6.

I keep src and pkgsrc trees on hard drive, GPT-partitioned, and do the compiling work on the hard drive.

One big advantage of current branch is using labels with NAME= in /etc/fstab, and not having to worry about the device name that will be assigned to the USB stick.

On NetBSD-current, I use GPT on the USB sticks with a root partition and swap partition, am not sure if swap partition is really needed, but just in case.

Boot code goes on root partition, and USB stick can be booted directly without GRUB or anything else special.

I do better with FreeBSD than NetBSD because of better stability, easier-to-handle device nodes, and ports system tends to work better than pkgsrc.

Tom

[Brett Lymn]

On Thu, Mar 27, 2014 at 03:44:19PM +0100, Ottavio Caruso wrote:
>
> Has anybody ever done it?
>

Sort of:

http://implementality.blogspot.com.au/2012/09/netbsd-on-stick.html

There is also:

http://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/

--
Brett Lymn
Staple Guns: because duct tape doesn't make that KerCHUNK sound - xkcd.com

[Brett Lymn]

On Fri, Mar 28, 2014 at 12:40:09PM +0100, Ottavio Caruso wrote:
> On 28 March 2014 12:33, Brett Lymn <***@internode.on.net> wrote:
> >
> > Sort of:
> >
> > http://implementality.blogspot.com.au/2012/09/netbsd-on-stick.html
> >
> > There is also:
> >
> > http://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/
>
>
> Thanks, but neither links are relevant. The first one is a plain
> installation on a USB stick (as opposed to a proper live-usb system),

Well, I did say "sort of" - really all you need after a base install is
to configure X to start and perhaps a desktop environment from pkgsrc.
With modern Xorg the X session should just fire up though the display
may not be optimal on recent video hardware - even this is being fixed.
Only a few days ago code was committed to enable drm.

> the second is about installing "from" not "to" a memory stick.
>

Yes, sorry - that was my error.

--
Brett Lymn
Staple Guns: because duct tape doesn't make that KerCHUNK sound - xkcd.com

[Chris Bannister]

On Fri, Mar 28, 2014 at 10:03:55PM +1030, Brett Lymn wrote:
> On Thu, Mar 27, 2014 at 03:44:19PM +0100, Ottavio Caruso wrote:
> >
> > Has anybody ever done it?
> >
>
> Sort of:
>
> http://implementality.blogspot.com.au/2012/09/netbsd-on-stick.html
>
> There is also:
>
> http://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/

Newbie question (hopefully not too stupid.)

How do you know when to use /dev/sd0a vs /dev/rsd0a

Found this, http://www.openbsd.org/faq/faq14.html
"... The device files would be /dev/sd0a for the block device,
/dev/rsd0a would be the device file for the "raw" (character) device."

Is that like /dev/sda1 vs /dev/sda in Linux, where /dev/sda represents
the whole device, and /dev/sda1 represents the first partition on
/dev/sda?

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[Christian Koch]

Hi Chris,

On Sat, Mar 29, 2014 at 02:07:46AM +1300, Chris Bannister wrote:
> How do you know when to use /dev/sd0a vs /dev/rsd0a

It depends on whether you need character-oriented or block-oriented access. For
example, you usually mount a disk in the block-device way, but OTOH it helps to
write a disklabel to a raw device.

Some man pages will you which access method is preferred, or at least which
methods are available.

On Sat, Mar 29, 2014 at 02:07:46AM +1300, Chris Bannister wrote:
> Found this, http://www.openbsd.org/faq/faq14.html
> "... The device files would be /dev/sd0a for the block device,
> /dev/rsd0a would be the device file for the "raw" (character) device."
>
> Is that like /dev/sda1 vs /dev/sda in Linux, where /dev/sda represents
> the whole device, and /dev/sda1 represents the first partition on
> /dev/sda?

The answer is no. Actually, you answered your own question. The NetBSD/OpenBSD
"r" convention has nothing to do with partitions -- it means, as you correctly
mention, that you want to access some device (and/or a particular partition) in
a character-oriented way (1 byte at a time), rather than a block-oriented way
(many bytes at a time).

For example, in NetBSD and OpenBSD you refer to the second partition of the
first sd(4) raw device like this: /dev/rsd0b ("0" == 1st device, "b" == 2nd
partition).

-Christian

[Ottavio Caruso]

On 28 March 2014 12:33, Brett Lymn <***@internode.on.net> wrote:
>
> Sort of:
>
> http://implementality.blogspot.com.au/2012/09/netbsd-on-stick.html
>
> There is also:
>
> http://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/


Thanks, but neither links are relevant. The first one is a plain
installation on a USB stick (as opposed to a proper live-usb system),
the second is about installing "from" not "to" a memory stick.

--
Ottavio

[Ottavio Caruso]

On 28 March 2014 12:49, Brett Lymn <***@internode.on.net> wrote:
> Well, I did say "sort of" - really all you need after a base install is
> to configure X to start and perhaps a desktop environment from pkgsrc.
> With modern Xorg the X session should just fire up though the display
> may not be optimal on recent video hardware - even this is being fixed.
> Only a few days ago code was committed to enable drm.

My biggest worry for now is a selection of packages that have a Dutch
locale. The form and the shape of the distribution is less relevant.
Although Dutch secondary school kids are fully fluent in English, the
foundation relies on distributing software that is available as much
as possible in their native language. I could double check this aspect
with the other members of the foundation.

I would be interested in having an image that can be easily copied and
installed on a flash drive, ideally without repartitioning the drive,
so that the student can reuse their drive either as a live usb or a as
portable storage for their own private files.


--
Ottavio

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 28 March 2014 12:49, Brett Lymn <***@internode.on.net> wrote:
>> Well, I did say "sort of" - really all you need after a base install is
>> to configure X to start and perhaps a desktop environment from pkgsrc.
>> With modern Xorg the X session should just fire up though the display
>> may not be optimal on recent video hardware - even this is being fixed.
>> Only a few days ago code was committed to enable drm.
>
> My biggest worry for now is a selection of packages that have a Dutch
> locale. The form and the shape of the distribution is less relevant.
> Although Dutch secondary school kids are fully fluent in English, the
> foundation relies on distributing software that is available as much
> as possible in their native language. I could double check this aspect
> with the other members of the foundation.
>
> I would be interested in having an image that can be easily copied and
> installed on a flash drive, ideally without repartitioning the drive,
> so that the student can reuse their drive either as a live usb or a as
> portable storage for their own private files.

I don't know about repartitioning, but another part, that is building
such images is well-tested to the point of creating USB and/or CF images
that start fully-functional (although barebone) NetBSD. Extending it to
install packages is not a problem. Extending it to building a given set
of packages is not a problem either. Thus all pieces are there, you only
need to gather them in single place and make it all run.

Remaining problems are:
- generating fully functional GPT-based images (those based on BSD label are fine though);
- deciding on the list of necessary packages;
- packaging missing bits.

If we really need dosboot, someone has to try it out.


--
HE CE3OH...

[Martin Husemann]

On Fri, Mar 28, 2014 at 09:17:46PM +0400, Aleksej Saushev wrote:
> If we really need dosboot, someone has to try it out.

It is a relict from Windows 9x or earlier -
it would only make sense from FreeDOS or similar nowadays.

But I don't understand why it would be needed, it is way easier to boot from
a USB stick for trying, or from already installed GRUB or Windows bootloader
if you want a bootmenu and a more permanent solution.

Martin

[Aleksej Saushev]

Martin Husemann <***@duskware.de> writes:

> On Fri, Mar 28, 2014 at 09:17:46PM +0400, Aleksej Saushev wrote:
>> If we really need dosboot, someone has to try it out.
>
> It is a relict from Windows 9x or earlier -
> it would only make sense from FreeDOS or similar nowadays.
>
> But I don't understand why it would be needed, it is way easier to boot from
> a USB stick for trying, or from already installed GRUB or Windows bootloader
> if you want a bootmenu and a more permanent solution.

As I understand original question, there's some wish to use media with original FAT32.
This is reasonable for various reasons like interoperability in the first place.
In this case it would be really nice to have solution that boots off FAT32.
Whether it is going to use FreeDOS or anything else doesn't matter as long
as it is small enough and functional.


--
HE CE3OH...

[Martin Husemann]

On Fri, Mar 28, 2014 at 11:57:42PM +0400, Aleksej Saushev wrote:
> As I understand original question, there's some wish to use media with original FAT32.

Like /usr/mdec/bootxx_msdos? This is a primary bootstrap which loads /boot
from a msdos partition.

Dosboot is like chainbooting from MS-DOS (running in real mode, not 32bit),
very hard to arrange for nowadays.

Martin

[Aleksej Saushev]

Martin Husemann <***@duskware.de> writes:

> On Fri, Mar 28, 2014 at 11:57:42PM +0400, Aleksej Saushev wrote:
>> As I understand original question, there's some wish to use media with original FAT32.
>
> Like /usr/mdec/bootxx_msdos? This is a primary bootstrap which loads /boot
> from a msdos partition.
>
> Dosboot is like chainbooting from MS-DOS (running in real mode, not 32bit),
> very hard to arrange for nowadays.

It is a bit of surprise to me that bootxx_msdos exists,
yet it isn't clear enough from documentation which file system(s) it supports.


--
HE CE3OH...

[Martin Husemann]

On Sat, Mar 29, 2014 at 12:52:40AM +0400, Aleksej Saushev wrote:
> It is a bit of surprise to me that bootxx_msdos exists,
> yet it isn't clear enough from documentation which file system(s) it supports.

(disclaimer: I've never used it)

>From the naming of other primaries in that directory my guess would be: just
msdos - so FAT and FAT32. If you can mount it with mount_msdos(8) [or the
equivalent mount -t msdos], it should work.

Martin

[Christos Zoulas]

In article <***@inbox.ru>, Aleksej Saushev <***@inbox.ru> wrote:
>Martin Husemann <***@duskware.de> writes:
>
>> On Fri, Mar 28, 2014 at 11:57:42PM +0400, Aleksej Saushev wrote:
>>> As I understand original question, there's some wish to use media
>with original FAT32.
>>
>> Like /usr/mdec/bootxx_msdos? This is a primary bootstrap which loads /boot
>> from a msdos partition.
>>
>> Dosboot is like chainbooting from MS-DOS (running in real mode, not 32bit),
>> very hard to arrange for nowadays.
>
>It is a bit of surprise to me that bootxx_msdos exists,
>yet it isn't clear enough from documentation which file system(s) it supports.
>

You can boot and run NetBSD on MSDOSFS root. Devices are handled by mounting
an mfs devfs, and permissions of course are not implemented etc.

christos

[Ottavio Caruso]

On 29 March 2014 20:32, Christos Zoulas <***@astron.com> wrote:
> You can boot and run NetBSD on MSDOSFS root. Devices are handled by mounting
> an mfs devfs, and permissions of course are not implemented etc.

Thanks Christos and others,

but as long as I understand the above mentioned process is involved
when you want to boot an "installed system" from fat/fat32.

What I was looking for instead, was a poor man's installation of a
live system, "live" as in live cd or live usb, for example an image
created with "mklivecd". But I might have misunderstood the whole
thing or explained myself incorrectly.


--
Ottavio

[Aleksej Saushev]

Hello,

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 29 March 2014 20:32, Christos Zoulas <***@astron.com> wrote:
>> You can boot and run NetBSD on MSDOSFS root. Devices are handled by mounting
>> an mfs devfs, and permissions of course are not implemented etc.
>
> Thanks Christos and others,
>
> but as long as I understand the above mentioned process is involved
> when you want to boot an "installed system" from fat/fat32.
>
> What I was looking for instead, was a poor man's installation of a
> live system, "live" as in live cd or live usb, for example an image
> created with "mklivecd". But I might have misunderstood the whole
> thing or explained myself incorrectly.

You ought to forget about "mklivecd", it stopped working about seven years ago.
After the introduction of ISO 9660 support to makefs(8) and after improvements
of kernel modules support it has become largely obsolete. If you're going to work
with mklivecd, you're going to spend time on fixing a tool to solve problems
that don't exist anymore.

Besides, in modern times there's very little (if any) need for live CD images,
live USB/SD media are easier to arrange, easier to handle, and easier to produce
at the same time. If you want to get the project done, you can safely ignore the
very existance of CD/DVD drives and focus on live USB memory stick or live SD card.
That doesn't mean that you should force everyone to abandon CD media completely,
still you can produce CD images if and after the real need arises.

In any case creating file system image is the easiest part of all this.
The hardest part is getting requirements right and packaging all this stuff correctly.


--
HE CE3OH...

[David Laight]

On Fri, Mar 28, 2014 at 01:38:30PM +0100, Ottavio Caruso wrote:
>
> I would be interested in having an image that can be easily copied and
> installed on a flash drive, ideally without repartitioning the drive,
> so that the student can reuse their drive either as a live usb or a as
> portable storage for their own private files.

The bootxx_fat16 (and bootxx_fat12) can be placed in the first sector
of a fat16 (or fat12) filesystem and will load /boot from that filesystem.
(They both read the filesystem metadata - they don't rely on a list of
sector numbers.)
One /boot is loaded it can load a kernel from any fat filesystem.

I've not tried to write a bootxx_fat32, I think it might be possible
because I believe there is usually more than one sector available.

Unfortunately most modern USB sticks are large enough to be FAT32.

On thing I did manage was to add a small mbr partition and FAT12
filesystem in the space before the main partition.
Setting this up was 'interesting'!
NetBSD's fdisk will do it from command line parameters, but the linux
one really won't let you.

David

--
David Laight: ***@l8s.co.uk

[Christos Zoulas]

In article <***@snowdrop.l8s.co.uk>,
David Laight <***@l8s.co.uk> wrote:
>On Fri, Mar 28, 2014 at 01:38:30PM +0100, Ottavio Caruso wrote:
>>
>> I would be interested in having an image that can be easily copied and
>> installed on a flash drive, ideally without repartitioning the drive,
>> so that the student can reuse their drive either as a live usb or a as
>> portable storage for their own private files.
>
>The bootxx_fat16 (and bootxx_fat12) can be placed in the first sector
>of a fat16 (or fat12) filesystem and will load /boot from that filesystem.
>(They both read the filesystem metadata - they don't rely on a list of
>sector numbers.)
>One /boot is loaded it can load a kernel from any fat filesystem.
>
>I've not tried to write a bootxx_fat32, I think it might be possible
>because I believe there is usually more than one sector available.

Heh, that would be nice to have.

>Unfortunately most modern USB sticks are large enough to be FAT32.
>
>On thing I did manage was to add a small mbr partition and FAT12
>filesystem in the space before the main partition.
>Setting this up was 'interesting'!
>NetBSD's fdisk will do it from command line parameters, but the linux
>one really won't let you.

In other news now you can use src/distrib/utils/embedded/mkimage to
create a usb image that contains an ffs filesystem that should be
bootable from any usb disk with ./mkimage -h amd64 -r sd

christos

[Ottavio Caruso]

On 2 April 2014 13:04, Christos Zoulas <***@astron.com> wrote:
> In other news now you can use src/distrib/utils/embedded/mkimage to
> create a usb image that contains an ffs filesystem that should be
> bootable from any usb disk with ./mkimage -h amd64 -r sd

Interesting. How would mkimage compare to /sysutils/mkmemstick/ ?

What kind of installation would come out if it?

I'd like to have something in ramdisk or /tmpfs rather that a full system.

--
Ottavio

[Christos Zoulas]

On Apr 3, 4:28pm, ottavio2006-***@yahoo.com (Ottavio Caruso) wrote:
-- Subject: Re: Making a localized, educational live-usb version of Netbsd? P

| On 2 April 2014 13:04, Christos Zoulas <***@astron.com> wrote:
| > In other news now you can use src/distrib/utils/embedded/mkimage to
| > create a usb image that contains an ffs filesystem that should be
| > bootable from any usb disk with ./mkimage -h amd64 -r sd
|
| Interesting. How would mkimage compare to /sysutils/mkmemstick/ ?

I don't know about mkmemstick. mkimage uses the tools in base to create
different kinds of memory images that can contain the various filesystems
makefs can create.

| What kind of installation would come out if it?

The default installation with or without x and debug sets depending on flags.

| I'd like to have something in ramdisk or /tmpfs rather that a full system.

I don't understand that. Meaning build the image in ramdisk?

christos

[Ottavio Caruso]

On 3 April 2014 19:10, Christos Zoulas <***@zoulas.com> wrote:
> | I'd like to have something in ramdisk or /tmpfs rather that a full system.
>
> I don't understand that. Meaning build the image in ramdisk?

To make myself clear: imagine Knoppix, but built on Netbsd.




--
Ottavio

[Christos Zoulas]

In article <***@mail.gmail.com>,
Ottavio Caruso <ottavio2006-***@yahoo.com> wrote:
>On 3 April 2014 19:10, Christos Zoulas <***@zoulas.com> wrote:
>> | I'd like to have something in ramdisk or /tmpfs rather that a full system.
>>
>> I don't understand that. Meaning build the image in ramdisk?
>
>To make myself clear: imagine Knoppix, but built on Netbsd.

That's a live filesystem from cd. I see. Not too hard to do, but I've not
done it yet. I think that most people these days have access to USB or CF.

christos

[Chris Bannister]

On Thu, Apr 03, 2014 at 07:22:34PM +0200, Ottavio Caruso wrote:
> On 3 April 2014 19:10, Christos Zoulas <***@zoulas.com> wrote:
> > | I'd like to have something in ramdisk or /tmpfs rather that a full system.
> >
> > I don't understand that. Meaning build the image in ramdisk?
>
> To make myself clear: imagine Knoppix, but built on Netbsd.

That would be great! If it isn't like that then it would be misleading
to call it a live system. (I vaguely recall downloading a so called live
BSD system, it might even have been a NetBSD one, and It was not what I
was expected.)

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[Dan LaBell]

On Apr 3, 2014, at 1:22 PM, Ottavio Caruso wrote:

> On 3 April 2014 19:10, Christos Zoulas <***@zoulas.com> wrote:
>> | I'd like to have something in ramdisk or /tmpfs rather that a
>> full system.
>>
>> I don't understand that. Meaning build the image in ramdisk?
>
> To make myself clear: imagine Knoppix, but built on Netbsd.
>
>
>
>
> --
> Ottavio

I've been following this thread for a bit...
So, you want to emulate Knoppix?
Sounds like might want to use virtual disks (with compression), so
checkout vnconfig ,
and union_mounts, so scripts, and users can make changes -- thumb
drives always seems to write
about half as fast as they read .. ( man 8 mount_union ) , and use
swap files instead of a b slice.
vndcompress(8) makes a cloop2 out of your .fs or file system image
file. I made a boot floppy --
-- root on usb / rescue thing for myself a while back, after
realizing Knoppix, and netbsd4live
would not really cut it for me ( for that purpose), but read some man
pages, and kidded myself about
easy it should be to make something like Knoppix ;-)
And, maybe you want to the thumbdrive to look as much a normal pc
thumbdrive w/o losing features
you need? (just to summarize the thread so far)

[Ottavio Caruso]

On 4 April 2014 15:31, Dan LaBell <dan4l-***@verizon.net> wrote:
.> So, you want to emulate Knoppix?

Not really. All I wanted to know was:

1) Is sysutils/mklivecd a good tool? I've been pointed out that it is not.
2) Can I start for an existing Netbsd-based live distro? Apparently
I've been told it's not a good idea.
3) What Netbsd applications are available in Dutch locale.






--
Ottavio

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 4 April 2014 15:31, Dan LaBell <dan4l-***@verizon.net> wrote:
> .> So, you want to emulate Knoppix?
>
> Not really. All I wanted to know was:
>
> 2) Can I start for an existing Netbsd-based live distro? Apparently
> I've been told it's not a good idea.

Sorry? It looks like a misinterpretation, since I didn't see this.
In fact, I'd say that it would be great to try it out.


--
HE CE3OH...

[Ottavio Caruso]

On 4 April 2014 21:13, Aleksej Saushev <***@inbox.ru> wrote:
>> 2) Can I start for an existing Netbsd-based live distro? Apparently
>> I've been told it's not a good idea.
>
> Sorry? It looks like a misinterpretation, since I didn't see this.
> In fact, I'd say that it would be great to try it out.

Then I misunderstood what you wrote here:
http://mail-index.netbsd.org/netbsd-users/2014/03/27/msg014342.html

I thought you meant it wasn't a good starting point. But I see you
have a project going on, so I'm looking forward to give a look at it
when it's ready.

--
Ottavio

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 4 April 2014 21:13, Aleksej Saushev <***@inbox.ru> wrote:
>>> 2) Can I start for an existing Netbsd-based live distro? Apparently
>>> I've been told it's not a good idea.
>>
>> Sorry? It looks like a misinterpretation, since I didn't see this.
>> In fact, I'd say that it would be great to try it out.
>
> Then I misunderstood what you wrote here:
> http://mail-index.netbsd.org/netbsd-users/2014/03/27/msg014342.html
>
> I thought you meant it wasn't a good starting point. But I see you
> have a project going on, so I'm looking forward to give a look at it
> when it's ready.

Alright, let me clarify that then.

Yes, assembling the disk is certainly possible. In fact, it would be
nice to have the project completed even if it isn't used by original
intended users afterwards.

Still it is a little involved on technical side. You have to learn some
things that may be unknown to you (if you call yourself a "newbie"),
and you certainly have to put some nontrivial amount of work into your
product. It is not a project for an evening.

No, previous LiveCD projects are not useful as starting points.
In fact, LiveCD is wrong approach to the problem in the modern time.


--
HE CE3OH...

[Ottavio Caruso]

On 5 April 2014 00:21, Aleksej Saushev <***@inbox.ru> wrote:
> No, previous LiveCD projects are not useful as starting points.
> In fact, LiveCD is wrong approach to the problem in the modern time.

I think it could be a good opportunity to try out a new OS for people
who don't want the aggravation of repartitioning, reinstalling,
applying new filesystems, compiling for sources, etc.

This is how I got started to Open Source 13 years ago. Actually my
first exposure to Unix was Picobsd on a floppy disk.

--
Ottavio

[Justin Cormack]

On Sat, Apr 5, 2014 at 12:38 PM, Ottavio Caruso
<ottavio2006-***@yahoo.com> wrote:
> On 5 April 2014 00:21, Aleksej Saushev <***@inbox.ru> wrote:
>> No, previous LiveCD projects are not useful as starting points.
>> In fact, LiveCD is wrong approach to the problem in the modern time.
>
> I think it could be a good opportunity to try out a new OS for people
> who don't want the aggravation of repartitioning, reinstalling,
> applying new filesystems, compiling for sources, etc.
>
> This is how I got started to Open Source 13 years ago. Actually my
> first exposure to Unix was Picobsd on a floppy disk.

I think Virtualbox images are the modern equivalent way to get
started. The main advantage over a USB live system is that you can
still use the host operating system to read the instructions while you
work out how to make it work. Virtualbox is available for most common
platforms, and is fairly simple to use. I think our images are getting
there.

Justin

[Chris Bannister]

On Sat, Apr 05, 2014 at 02:54:11PM +0100, Justin Cormack wrote:
> I think Virtualbox images are the modern equivalent way to get
> started. The main advantage over a USB live system is that you can
> still use the host operating system to read the instructions while you
> work out how to make it work.

Au contraire, a live system by its very nature just works, the host
system is not touched at all *UNLESS* you jump through hoops to make it
so, e.g. mounting the host HDD, then chrooting into it, etc.

You boot off the live system media. Using virtualbox or whatever is a
completely different kettle of fish altogether.

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 5 April 2014 00:21, Aleksej Saushev <***@inbox.ru> wrote:
>> No, previous LiveCD projects are not useful as starting points.
>> In fact, LiveCD is wrong approach to the problem in the modern time.
>
> I think it could be a good opportunity to try out a new OS for people
> who don't want the aggravation of repartitioning, reinstalling,
> applying new filesystems, compiling for sources, etc.
>
> This is how I got started to Open Source 13 years ago. Actually my
> first exposure to Unix was Picobsd on a floppy disk.

LiveCD is of no use to people who have no functional CD drive
or no CD drive at all. This is why it is the wrong approach.


--
HE CE3OH...

[Ottavio Caruso]

On 5 April 2014 16:56, Aleksej Saushev <***@inbox.ru> wrote:
> LiveCD is of no use to people who have no functional CD drive
> or no CD drive at all. This is why it is the wrong approach.


By livecd I meant any system which is not installed to local hard disk
and resets itself after reboot. It doesn't have to boot from a CD, it
can boot from any removable media, the principle is the same.

--
Ottavio

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 5 April 2014 16:56, Aleksej Saushev <***@inbox.ru> wrote:
>> LiveCD is of no use to people who have no functional CD drive
>> or no CD drive at all. This is why it is the wrong approach.
>
> By livecd I meant any system which is not installed to local hard disk
> and resets itself after reboot. It doesn't have to boot from a CD, it
> can boot from any removable media, the principle is the same.

Live CD is significantly different from live USB pen drive and SD card,
it has to be in a separate category because building it is based on
completely different principle. Same for live DVD.
Because "any removable medium" covers CD and DVD, you should stop
thinking about "any removable medium" and think about useful ones.

This also explains why mklivecd and other live CD products are useless.
They point you in the direction of working around limitations of hardware
that is largely irrelevant to your needs. USB pen drives and SD cards
are almost like regular hard drives. They free you from those limitations,
so you can concentrate on solving your immediate problems.

Once you understand that what you actually want is basically an image of
hard drive of small capacity, you'll understand that you could have
prepared some early prototype of your system already. This is really
a matter of three-four hours as I tested when wrote the script mentioned
in this message:

From: Aleksej Saushev <***@inbox.ru>
Subject: Re: Anyone working on an automated install?
To: tech-***@netbsd.org
Date: Mon, 29 Oct 2012 01:30:02 +0400
Message-ID: <***@inbox.ru>

(also archived as https://mail-index.netbsd.org/tech-install/2012/10/28/msg000360.html)

Since that time the script was improved a little.


--
HE CE3OH...

[Ottavio Caruso]

On 6 April 2014 13:33, Aleksej Saushev <***@inbox.ru> wrote:
> Once you understand that what you actually want is basically an image of
> hard drive of small capacity, you'll understand that you could have
> prepared some early prototype of your system already.

I'm sorry but I disagree. There's a reason why somebody wants to load
a read-only filesystem as opposed to a proper installation. What about
the countless Linux live-usb distributions around? Are they all going
in the wrong directions? And all the millions of downloads?

> This is really
> a matter of three-four hours as I tested when wrote the script mentioned
> in this message:
>
> From: Aleksej Saushev <***@inbox.ru>
> Subject: Re: Anyone working on an automated install?
> To: tech-***@netbsd.org
> Date: Mon, 29 Oct 2012 01:30:02 +0400
> Message-ID: <***@inbox.ru>
>
> (also archived as https://mail-index.netbsd.org/tech-install/2012/10/28/msg000360.html)

Good script but this is not what I was talking about.


--
Ottavio Caruso

[Aleksej Saushev]

Ottavio Caruso <***@googlemail.com> writes:

> On 6 April 2014 13:33, Aleksej Saushev <***@inbox.ru> wrote:
>> Once you understand that what you actually want is basically an image of
>> hard drive of small capacity, you'll understand that you could have
>> prepared some early prototype of your system already.
>
> I'm sorry but I disagree. There's a reason why somebody wants to load
> a read-only filesystem as opposed to a proper installation.

What is the reason then?

Booting a system installed on SD card does not imply replacing the one
installed on your hard drive (as implied by your "proper installation").

Applied to your project, is it a requirement or of any necessity?

> What about
> the countless Linux live-usb distributions around? Are they all going
> in the wrong directions? And all the millions of downloads?

Do they all use read-only file systems?

I say it again, if you stop thinking in terms of read-only medium,
you'll procede much faster. In particular, you'll be able to come up
with an early prototype in several hours. This is the main reason
why I say that live CD is the wrong approach to your problem:
you put up an irrelevant requirement that doesn't affect main
functionality and this precludes you from making progress.


--
HE CE3OH...

[Ottavio Caruso]

On 6 April 2014 17:14, Aleksej Saushev <***@inbox.ru> wrote:
> What is the reason then?
>
> Booting a system installed on SD card does not imply replacing the one
> installed on your hard drive (as implied by your "proper installation").
>
> Applied to your project, is it a requirement or of any necessity?

I'm no longer actively working at this project (they have decided to
go for Edubuntu) but, yes, in my case the usb pendrive should have
been given to young students, and in this case it's paramount that
they don't mess up with the installation.

>
>> What about
>> the countless Linux live-usb distributions around? Are they all going
>> in the wrong directions? And all the millions of downloads?
>
> Do they all use read-only file systems?

I'm surprised that you ask this question at all.
http://en.wikipedia.org/wiki/Live_USB

Quote:
======
Live USBs are closely related to live CDs, but sometimes have the
ability to persistently save settings and permanently install software
packages back onto the USB device. Like live CDs, live USBs can be
used in embedded systems for system administration, data recovery, or
the testing of operating system distributions without committing to a
permanent installation on the local hard disk drive.
=======

Here you go: "without committing to a permanent installation" is my reason.

I have just used SytstemRescueCd (on a usb stick) to repartition my
hard drive and make room for Netbsd.

--
Ottavio

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 6 April 2014 17:14, Aleksej Saushev <***@inbox.ru> wrote:
>> What is the reason then?
>>
>> Booting a system installed on SD card does not imply replacing the one
>> installed on your hard drive (as implied by your "proper installation").
>>
>> Applied to your project, is it a requirement or of any necessity?
>
> I'm no longer actively working at this project (they have decided to
> go for Edubuntu) but, yes, in my case the usb pendrive should have
> been given to young students, and in this case it's paramount that
> they don't mess up with the installation.

This doesn't answer the question.

"Don't mess up with the installation" is one thing,
"read-only file system" (like on live CD) is completely different one.
It looks like you don't see this very important difference.

>>> What about
>>> the countless Linux live-usb distributions around? Are they all going
>>> in the wrong directions? And all the millions of downloads?
>>
>> Do they all use read-only file systems?
>
> I'm surprised that you ask this question at all.
> http://en.wikipedia.org/wiki/Live_USB
>
> Quote:
> ======
> Live USBs are closely related to live CDs, but sometimes have the
> ability to persistently save settings and permanently install software
> packages back onto the USB device. Like live CDs, live USBs can be
> used in embedded systems for system administration, data recovery, or
> the testing of operating system distributions without committing to a
> permanent installation on the local hard disk drive.
> =======

This doesn't answer the question either.

> Here you go: "without committing to a permanent installation" is my reason.

"Without committing to a permanent installation" makes no sense at all
unless we're discussing burning NetBSD into PROM.

"Without committing to installation to internal HDD" is completely
different thing. Using a system that is installed to USB-attached storage,
be it pen drive or external HDD, or installed to SD or CF card (perhaps
used via USB card reader) satisfies this requirement perfectly.


--
HE CE3OH...

[Eric Haszlakiewicz]

On April 6, 2014 7:33:34 AM EDT, Aleksej Saushev <***@inbox.ru> wrote:
>Ottavio Caruso <ottavio2006-***@yahoo.com> writes:
>
>> On 5 April 2014 16:56, Aleksej Saushev <***@inbox.ru> wrote:
>>> LiveCD is of no use to people who have no functional CD drive
>>> or no CD drive at all. This is why it is the wrong approach.
>>
>> By livecd I meant any system which is not installed to local hard
>disk
>> and resets itself after reboot. It doesn't have to boot from a CD, it
>> can boot from any removable media, the principle is the same.
>
>Live CD is significantly different from live USB pen drive and SD card,
>it has to be in a separate category because building it is based on
>completely different principle. Same for live DVD.

How is it any different? In both cases you create a boot image that you don't change, and boot it on a machine whose existing installation you don't change. That seems pretty similar to me.
The fact that in one case the media physically prevents you from modifying it seems largely irrelevant.

Eric

[Aleksej Saushev]

Eric Haszlakiewicz <***@nimenees.com> writes:

> On April 6, 2014 7:33:34 AM EDT, Aleksej Saushev <***@inbox.ru> wrote:
>>Ottavio Caruso <ottavio2006-***@yahoo.com> writes:
>>
>>> On 5 April 2014 16:56, Aleksej Saushev <***@inbox.ru> wrote:
>>>> LiveCD is of no use to people who have no functional CD drive
>>>> or no CD drive at all. This is why it is the wrong approach.
>>>
>>> By livecd I meant any system which is not installed to local hard
>>disk
>>> and resets itself after reboot. It doesn't have to boot from a CD, it
>>> can boot from any removable media, the principle is the same.
>>
>>Live CD is significantly different from live USB pen drive and SD card,
>>it has to be in a separate category because building it is based on
>>completely different principle. Same for live DVD.
>
> How is it any different? In both cases you create a boot image
> that you don't change, and boot it on a machine whose existing
> installation you don't change. That seems pretty similar to me.
> The fact that in one case the media physically prevents you from modifying it seems largely irrelevant.

It is relevant and this is exactly what constitutes major difference
when you work on such a project. You don't need to think how to handle
various things that require data persistency even if temporal one.
Your /tmp and /var are writable from the very beginning as if you are
using HDD. This alone makes USB pen drive a lot different to place it
into another category.

Even if you decide to install some additional software, you don't need
to create the image from scratch, with USB pen drive you follow the usual
routine.


--
HE CE3OH...

[Eric Haszlakiewicz]

On April 6, 2014 1:52:29 PM EDT, Aleksej Saushev <***@inbox.ru> wrote:
>Eric Haszlakiewicz <***@nimenees.com> writes:
>
>> On April 6, 2014 7:33:34 AM EDT, Aleksej Saushev <***@inbox.ru>
>wrote:
>>>Ottavio Caruso <ottavio2006-***@yahoo.com> writes:
>>>
>>>> On 5 April 2014 16:56, Aleksej Saushev <***@inbox.ru> wrote:
>>>>> LiveCD is of no use to people who have no functional CD drive
>>>>> or no CD drive at all. This is why it is the wrong approach.
>>>>
>>>> By livecd I meant any system which is not installed to local hard
>>>disk
>>>> and resets itself after reboot. It doesn't have to boot from a CD,
>it
>>>> can boot from any removable media, the principle is the same.
>>>
>>>Live CD is significantly different from live USB pen drive and SD
>card,
>>>it has to be in a separate category because building it is based on
>>>completely different principle. Same for live DVD.
>>
>> How is it any different? In both cases you create a boot image
>> that you don't change, and boot it on a machine whose existing
>> installation you don't change. That seems pretty similar to me.
>> The fact that in one case the media physically prevents you from
>modifying it seems largely irrelevant.
>
>It is relevant and this is exactly what constitutes major difference
>when you work on such a project. You don't need to think how to handle
>various things that require data persistency even if temporal one.
>Your /tmp and /var are writable from the very beginning as if you are
>using HDD. This alone makes USB pen drive a lot different to place it
>into another category.

Well, you clearly have a different idea of what a "live usb" system is than I do. I expected it to be something that could be booted repeatedly and have the exact same environment each time (i.e. no changes allowed to the usb storage), while you seem to be talking about just a normal install on a usb stick.

>Even if you decide to install some additional software, you don't need
>to create the image from scratch, with USB pen drive you follow the
>usual
>routine.

How the image is created seems to me like something that is not at all relevant to how it is used, and I imagine that 99% of the time will be people *using* a pre-made image, not creating their own. The times that I've used livecd images the grab-it-and-go feature has been the biggest reason for using it, so I don't care what steps might have been needed to create it.

Eric

[Aleksej Saushev]

Eric Haszlakiewicz <***@nimenees.com> writes:

> On April 6, 2014 1:52:29 PM EDT, Aleksej Saushev <***@inbox.ru> wrote:
>>It is relevant and this is exactly what constitutes major difference
>>when you work on such a project. You don't need to think how to handle
>>various things that require data persistency even if temporal one.
>>Your /tmp and /var are writable from the very beginning as if you are
>>using HDD. This alone makes USB pen drive a lot different to place it
>>into another category.
>
> Well, you clearly have a different idea of what a "live usb"
> system is than I do. I expected it to be something that could be
> booted repeatedly and have the exact same environment each time
> (i.e. no changes allowed to the usb storage), while you seem to
> be talking about just a normal install on a usb stick.

If we want to use this definition, I'd argue that "live USB" in your
sense is wrong approach to attack this particular problem.
"No changes allowed" is rather strange for an educational platform,
it means that you cannot save your work across reboots (so that you
could revisit it in a week or in a month, for instance) except on
another medium (which is, most probably, another USB pen drive).

>>Even if you decide to install some additional software, you don't need
>>to create the image from scratch, with USB pen drive you follow the
>>usual
>>routine.
>
> How the image is created seems to me like something that is not
> at all relevant to how it is used, and I imagine that 99% of the
> time will be people *using* a pre-made image, not creating their
> own.

Sure, for end user it doesn't matter. One of original questions was
about how to create such images and if a "newbie" can do this.

> The times that I've used livecd images the grab-it-and-go
> feature has been the biggest reason for using it, so I don't
> care what steps might have been needed to create it.

I don't think that grab-it-and-go requires that it provides exactly
the same environment across reboots. Perhaps, the latter has its use,
but I'm not sure it is needed that often.


--
HE CE3OH...

[Ottavio Caruso]

On 6 April 2014 23:14, Aleksej Saushev <***@inbox.ru> wrote:
> If we want to use this definition, I'd argue that "live USB" in your
> sense is wrong approach to attack this particular problem.
> "No changes allowed" is rather strange for an educational platform,
> it means that you cannot save your work across reboots (so that you
> could revisit it in a week or in a month, for instance) except on
> another medium (which is, most probably, another USB pen drive).

Well, that's exactly what is expected: you lend a USB pen to 10 year
old and you don't want him/her to scr*w up with the pen because next
week you're going to hand it over to some other kid. You just want to
give a presentation of your project and that's it.

Besides, a traditional read/write installed system on a USB2 pendrive
is damn slow. A compressed filesystem like squash or a more
old-fashioned cloop is way faster.

This doesn't rule out that you can partition the usb drive and make
some part of the fs permanent. Once could mount /usr/pkg and /home on
separate partition and have a fully functional hybrid installation.

Knoppix and Casper (Ubuntu) use FUSE to back up changes to a permanent
location at some intervals. Damn Small Linux uses a clever, poorman's
script to back up /home and /etc to a file and restore them upon boot.

--
Ottavio

[Aleksej Saushev]

Ottavio Caruso <ottavio2006-***@yahoo.com> writes:

> On 6 April 2014 23:14, Aleksej Saushev <***@inbox.ru> wrote:
>> If we want to use this definition, I'd argue that "live USB" in your
>> sense is wrong approach to attack this particular problem.
>> "No changes allowed" is rather strange for an educational platform,
>> it means that you cannot save your work across reboots (so that you
>> could revisit it in a week or in a month, for instance) except on
>> another medium (which is, most probably, another USB pen drive).
>
> Well, that's exactly what is expected: you lend a USB pen to 10 year
> old and you don't want him/her to scr*w up with the pen because next
> week you're going to hand it over to some other kid. You just want to
> give a presentation of your project and that's it.

I'm not native English speaker either, yet given that I've heard words
"screw it (up)" in old movies intended for school age audience, they are
definitly not obscene.

Anyway, what do you call "screw it up"? If a talented boy decides to
disassemble it to look what is inside, you're not going to repair it.
If he runs "rm -rf /" and waits till it erases files into his home
directory, repair takes getting into root shell and running a command
to erase what remains and copy user skeleton into now empty home directory.
If he is talented enough to break into the root shell to run fdisk or
anything else to write to the device, you cannot stop it.
Besides, even in this case restoring your USB pen takes five minutes
of your machine time (not your personal time even!) to write that
single gigabyte of initial image to reset it all back.

> Besides, a traditional read/write installed system on a USB2 pendrive
> is damn slow. A compressed filesystem like squash or a more
> old-fashioned cloop is way faster.

What is this strange use case that requires really fast reads and writes?
Movies are fine to watch from SDHC card. Music is more that just fine to
listen, all "high-end" MP3 players use this technology not to mention
those you buy for 10-20 EUR. You're not going to win TPC mark or run
quantum chemistry calculations with avergage commodity hardware in any case.

> This doesn't rule out that you can partition the usb drive and make
> some part of the fs permanent. Once could mount /usr/pkg and /home on
> separate partition and have a fully functional hybrid installation.
>
> Knoppix and Casper (Ubuntu) use FUSE to back up changes to a permanent
> location at some intervals. Damn Small Linux uses a clever, poorman's
> script to back up /home and /etc to a file and restore them upon boot.

Sure, there was even linux system based on CD-R and CD-RW that jumped
through the hoops to overcome limitations of CD hardware in order to
allow users some limited form of persistence. Why is that needed with
medium that is easily rewritable? Are you trying to create more problems
in order to solve them and show your heroism.

You know what? I can only congratulate you that you have screwed this
project up. It could be short, interesting, and fun. You could have
learnt something useful while working on it. Instead you have turned it
into boring corporate-style task by introduction of requireiments
irrelevant (if not harfmul) to end users. All the stuff that really matters:
the end software, its availability through pkgsrc, and its portability to
NetBSD wasn't even discussed.


--
HE CE3OH...

[David Lord]

On 6 Apr 2014 at 15:27, Eric Haszlakiewicz wrote:

> On April 6, 2014 1:52:29 PM EDT, Aleksej Saushev <***@inbox.ru> wrote:
> >Eric Haszlakiewicz <***@nimenees.com> writes:
> >
> >> On April 6, 2014 7:33:34 AM EDT, Aleksej Saushev <***@inbox.ru>
> >wrote:
> >>>Ottavio Caruso <ottavio2006-***@yahoo.com> writes:
> >>>
> >>>> On 5 April 2014 16:56, Aleksej Saushev <***@inbox.ru> wrote:
> >>>>> LiveCD is of no use to people who have no functional CD drive
> >>>>> or no CD drive at all. This is why it is the wrong approach.
> >>>>
> >>>> By livecd I meant any system which is not installed to local hard
> >>>disk
> >>>> and resets itself after reboot. It doesn't have to boot from a CD,
> >it
> >>>> can boot from any removable media, the principle is the same.
> >>>
> >>>Live CD is significantly different from live USB pen drive and SD
> >card,
> >>>it has to be in a separate category because building it is based on
> >>>completely different principle. Same for live DVD.
> >>
> >> How is it any different? In both cases you create a boot image
> >> that you don't change, and boot it on a machine whose existing

Hi

I must be from a different world?

My usb drives have been writeable, at least from a root
login, and I accidentally destroyed my first one. That is
a big disadvantage but not as important as being able to
just change config or update as one does with NetBSD on hdd.


David


> >> installation you don't change. That seems pretty similar to me.
> >> The fact that in one case the media physically prevents you from
> >modifying it seems largely irrelevant.
> >
> >It is relevant and this is exactly what constitutes major difference
> >when you work on such a project. You don't need to think how to handle
> >various things that require data persistency even if temporal one.
> >Your /tmp and /var are writable from the very beginning as if you are
> >using HDD. This alone makes USB pen drive a lot different to place it
> >into another category.
>
> Well, you clearly have a different idea of what a "live usb" system is than I do. I expected it to be something that could be booted repeatedly and have the exact same environment each time (i.e. no changes allowed to the usb storage), while you seem to be talking about just a normal install on a usb stick.
>
> >Even if you decide to install some additional software, you don't need
> >to create the image from scratch, with USB pen drive you follow the
> >usual
> >routine.
>
> How the image is created seems to me like something that is not at all relevant to how it is used, and I imagine that 99% of the time will be people *using* a pre-made image, not creating their own. The times that I've used livecd images the grab-it-and-go feature has been the biggest reason for using it, so I don't care what steps might have been needed to create it.
>
> Eric
>

[David Lord]

On 4 Apr 2014 at 21:45, Ottavio Caruso wrote:

> On 4 April 2014 21:13, Aleksej Saushev <***@inbox.ru> wrote:
> >> 2) Can I start for an existing Netbsd-based live distro? Apparently
> >> I've been told it's not a good idea.
> >
> > Sorry? It looks like a misinterpretation, since I didn't see this.
> > In fact, I'd say that it would be great to try it out.
>
> Then I misunderstood what you wrote here:
> http://mail-index.netbsd.org/netbsd-users/2014/03/27/msg014342.html
>
> I thought you meant it wasn't a good starting point. But I see you
> have a project going on, so I'm looking forward to give a look at it
> when it's ready.
>

My attempts at an install system from a usb stick
eventually worked well and was useful on my systems
without cdrom drive. Unfortunately I managed to
overwrite it. There were two downsides to my usb
stick, although on a 16 G stick I only had about
500 MB of space with install system taking up most
of that, secondly it was painfully slow.

I've just now reinstalled the stick with 5 GB used
for the filesystem:

Filesystem Size Used Avail
root_device 4.9G 443M 4.2G

It needs some cleaning up but it boots ok.

I also have NetBSD-6.1_STABLE-i386-live-sd0root.img.gz
built from sysbuild, that can be transferred using 'dd'.


David

[Béla]

Hi guys,
Anybody using dwm out there? I'm quite new to NetBSD... I want to
recompile dwm in pkgsrc with a custom config.h file but I have no idea
how to do this. Under FreeBSD it would be something like:
make DWM_CONF=/path/to/config.h
How do I get the same result under NetBSD?
Thx!
Béla.

[atomicules]

Hi Béla,

On 05-Apr-2014 13:34:17, Béla wrote:
>Hi guys,
>Anybody using dwm out there? I'm quite new to NetBSD...

I'm using dwm, but not via pkgsrc, just straight from the suckless
repository, which makes dealing with config.def.h easier.

>recompile dwm in pkgsrc with a custom config.h file but I have no idea
>how to do this.

One option would be to get your changes for config.def.h in the
form of a patch and use the local patches option of pkgsrc to pull
them in, if you want to use pkgsrc for dwm. That should work really
well.

[Chris Bannister]

On Sat, Apr 05, 2014 at 01:34:17PM +0200, Béla wrote:
> Hi guys,
> Anybody using dwm out there? I'm quite new to NetBSD... I want to

Please don't hijack threads. IOW, start a new message for a new topic,
don't just grab an existing message and change the subject.

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[Béla]

Sorry, my mistake

On 04/06/2014 10:45, Chris Bannister wrote:
> On Sat, Apr 05, 2014 at 01:34:17PM +0200, Béla wrote:
>> Hi guys,
>> Anybody using dwm out there? I'm quite new to NetBSD... I want to
>
> Please don't hijack threads. IOW, start a new message for a new topic,
> don't just grab an existing message and change the subject.
>

[Chris Bannister]

On Sat, Apr 05, 2014 at 09:24:31AM -0000, David Lord wrote:
>
> My attempts at an install system from a usb stick
> eventually worked well and was useful on my systems
> without cdrom drive. Unfortunately I managed to
> overwrite it. There were two downsides to my usb
> stick, although on a 16 G stick I only had about
> 500 MB of space with install system taking up most
> of that, secondly it was painfully slow.
>
> I've just now reinstalled the stick with 5 GB used
> for the filesystem:
>
> Filesystem Size Used Avail
> root_device 4.9G 443M 4.2G

Can it be extended to use the whole 16G? That could be handy as a
transportable Live system.

> It needs some cleaning up but it boots ok.
>
> I also have NetBSD-6.1_STABLE-i386-live-sd0root.img.gz
> built from sysbuild, that can be transferred using 'dd'.

And this can be dd'd to a USB stick as a bootable live system? Is it
possible to extend the image to use all the space on the USB stick?

--
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the
oppressing." --- Malcolm X

[David Lord]

On 6 Apr 2014 at 4:12, Chris Bannister wrote:

> On Sat, Apr 05, 2014 at 09:24:31AM -0000, David Lord wrote:
> >
> > My attempts at an install system from a usb stick
> > eventually worked well and was useful on my systems
> > without cdrom drive. Unfortunately I managed to
> > overwrite it. There were two downsides to my usb
> > stick, although on a 16 G stick I only had about
> > 500 MB of space with install system taking up most
> > of that, secondly it was painfully slow.
> >
> > I've just now reinstalled the stick with 5 GB used
> > for the filesystem:
> >
> > Filesystem Size Used Avail
> > root_device 4.9G 443M 4.2G
>
> Can it be extended to use the whole 16G? That could be handy as a
> transportable Live system.

Hi

No problem, I intended adding a couple of extra fdisk
partitions.


> > It needs some cleaning up but it boots ok.
> >
> > I also have NetBSD-6.1_STABLE-i386-live-sd0root.img.gz
> > built from sysbuild, that can be transferred using 'dd'.
>
> And this can be dd'd to a USB stick as a bootable live system? Is it
> possible to extend the image to use all the space on the USB stick?

I've not found an option to set the image size but dummy
files could be added to the iso directory and then once
the image is dd'd to the usb stick it should be possible
to delete the dummy files to create some free space.

Having played with the usb stick for a while, I'd say
its use would be limited to doing system updates since
writes to the stick are very very slow.


I've also tried mklivecd which has an iso directory the
contents of which can be changed before generation of the
iso file. I've not yet burnt a cd to test it.


David

>
> --
> "If you're not careful, the newspapers will have you hating the people
> who are being oppressed, and loving the people who are doing the
> oppressing." --- Malcolm X

[Aleksej Saushev]

Chris Bannister <***@slingshot.co.nz> writes:

> On Sat, Apr 05, 2014 at 09:24:31AM -0000, David Lord wrote:
>>
>> My attempts at an install system from a usb stick
>> eventually worked well and was useful on my systems
>> without cdrom drive. Unfortunately I managed to
>> overwrite it. There were two downsides to my usb
>> stick, although on a 16 G stick I only had about
>> 500 MB of space with install system taking up most
>> of that, secondly it was painfully slow.
>>
>> I've just now reinstalled the stick with 5 GB used
>> for the filesystem:
>>
>> Filesystem Size Used Avail
>> root_device 4.9G 443M 4.2G
>
> Can it be extended to use the whole 16G? That could be handy as a
> transportable Live system.
>
>> It needs some cleaning up but it boots ok.
>>
>> I also have NetBSD-6.1_STABLE-i386-live-sd0root.img.gz
>> built from sysbuild, that can be transferred using 'dd'.
>
> And this can be dd'd to a USB stick as a bootable live system? Is it
> possible to extend the image to use all the space on the USB stick?

makefs(8) has some flags to set free space on the file system and/or
to set total size of file system image.


--
HE CE3OH...

[Alistair Crooks]

On the topic of a live/lightweight installs, check out httpdev:

http://cvsweb.netbsd.org/bsdweb.cgi/othersrc/external/bsd/httpdev/Makefile?only_with_tag=MAIN

which uses rump, and ReFUSE to mount a remote ISO on a remote
webserver.

It would save all that hassle with downloading huge images, or binary
sets, writing them to USB sticks, etc.

Regards,
Alistair

[David Laight]

On Wed, Apr 02, 2014 at 11:04:41AM +0000, Christos Zoulas wrote:
> >
> > I've not tried to write a bootxx_fat32, I think it might be possible
> > because I believe there is usually more than one sector available.
>
> Heh, that would be nice to have.

I recall deciding that even I couldn't fit the fat32 code into the
480ish bytes available in a pbr.

Reading a list of sectors is cheating and prone to errors.


David

--
David Laight: ***@l8s.co.uk

[Christos Zoulas]

On Apr 3, 11:34pm, ***@l8s.co.uk (David Laight) wrote:
-- Subject: Re: Making a localized, educational live-usb version of Netbsd? P

| I recall deciding that even I couldn't fit the fat32 code into the
| 480ish bytes available in a pbr.

A challenge :-)

| Reading a list of sectors is cheating and prone to errors.

I agree.

christos