Date: Wed, 5 Dec 2012 01:34:11 +0200 From: Alexander Yerenkow <yerenkow@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Garrett Cooper <yanegomi@gmail.com>, lev@freebsd.org, freebsd-current <freebsd-current@freebsd.org> Subject: Re: FreeBSD as read-only firmware Message-ID: <CAPJF9wkhUkufj1PXonzUk-ZpA0iXye_zqKMTocL-Ukfwr2f-sg@mail.gmail.com> In-Reply-To: <80F27F05-232F-4014-98C5-31AC5FCF2188@bsdimp.com> References: <CAPJF9wmO-oO7cy4XUwnTMb5cpD14TaK430rWW2nqodBFWw54DQ@mail.gmail.com> <1167404891.20121103170049@serebryakov.spb.ru> <CAPJF9wmVPxMDBqyy=Dqdnb%2BZ33f_wLDx9CFbk_oSEx4inboK6A@mail.gmail.com> <CAGH67wQORX7_N6-ggpeaLFzj0Gcy9H64EO91gHi2pcuGTE3CfQ@mail.gmail.com> <CAPJF9w=x%2BiSN9BuEcq8KOM7px1-B_n0oDfeFsyWkWesTCLDjhw@mail.gmail.com> <534994431.20121104025602@serebryakov.spb.ru> <80F27F05-232F-4014-98C5-31AC5FCF2188@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/12/4 Warner Losh <imp@bsdimp.com>
> [ replying to an old thread, sorry ]
>
> On Nov 3, 2012, at 4:56 PM, Lev Serebryakov wrote:
>
> > Hello, Alexander.
> > You wrote 4 =CE=CF=D1=C2=D2=D1 2012 =C7., 2:12:03:
> >
> > AY> Quick glance to nanobsd give me impression that:
> > AY> 1) nanobsd is MBR based, so :
> > AY> 2) nanobsd is disk-name-change sensitive.
> > Here are patches to support GPT
>
> I'd love to see those... The mailing list must have eaten the original
> ones.
>
> > AY> GPT way is better - I'm using r${REV} as label, and root can be
> mounted no
> > AY> matter how many other "firmware's" present, or how disks are ordere=
d.
> >
> > AY> BTW, due to bug 173309 I had to rebuild and update my server, which
> took
> > AY> only few minutes for reboot.
> >
> > AY> Well, nanobsd is great thing, I'll look into it a bit more, but it'=
s
> goal
> > AY> to have minified FreeBSD, while I need read-only one.
> > No. Its goal is to have RO and ACID-upgradable system (with two code
> > slices for this).
>
> Yes. NanoBSD's way isn't the best, and if there's better ways for it to d=
o
> its thing, then I'm all for updating it to cope better. I have a bit of =
a
> backlog of NanoBSD patches to get to, which is why this caught my eye, an=
d
> since 9.1 will soon be a totally done deal, what better time to hack on
> NanoBSD and merge...
>
I'm using these simple scripts
https://github.com/yerenkow/freebsd-vm-image/tree/master/freebsd-firmware
to build RO-images both for VMs and for SD cards (GPT or MBR for buggy
BIOSes). I don't like idea of upgrading something (via some doubling
partitions, or else), at this stage; it's still potential room for problems=
.
Have one release image fully replaced by other release image - is what
seems fit for my goals and requirements; possibility of adding some
checksums would be nice too.
Probably this could be implemented in nanoBSD too.
>
> Warner
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org=
"
--=20
Regards,
Alexander Yerenkow
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPJF9wkhUkufj1PXonzUk-ZpA0iXye_zqKMTocL-Ukfwr2f-sg>