DVD burner failure on FreeBSD: the LUN appears to be stuck
I have DVD burner Pioneer DVR-112D failing on FreeBSD-9.1 amd64. It begins to write ok, but later gets stuck at some percentage point with "the LUN appears to be stuck" message (log is below). Command used to burn is: $ growisofs -dvd-compat -speed=4 -Z /dev/acd0=my.iso growisofs is from dvd+rw-tools-7.1, which hasn't been updated from 2008. cd0: Removable CD-ROM SCSI-0 device Now there is a dilemma. Does this mean that the burner went bad? Or does this mean that there is some fault in the burner driver? I know that few years ago this burner worked fine on BSD. Maybe anybody has an expertise and would know if this error means the hardware or software failure? Anybody is able to burn DVDs with the same/similar burner? Or maybe some other command should be used for burning? (growisofs is recommended by the handbook) Googling the message doesn't clarify the issue. Yuri --- error log --- 1072726016/8061945856 (13.3%) @0.0x, remaining 86:00 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 86:19 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 86:45 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 87:05 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 87:24 RBU 100.0% UBU 100.0% 072726016/8061945856 (13.3%) @0.0x, remaining 87:50 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 88:10 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 88:30 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 88:56 RBU 100.0% UBU 100.0% :-? the LUN appears to be stuck writing LBA=7fe10h, keep retrying in 141ms 1072726016/8061945856 (13.3%) @0.0x, remaining 89:15 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 89:35 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 90:01 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 90:20 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 90:40 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 91:06 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 91:25 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 91:45 RBU 100.0% UBU 100.0% :-? the LUN appears to be stuck writing LBA=7fe10h, keep retrying in 141ms 1072726016/8061945856 (13.3%) @0.0x, remaining 92:11 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 92:31 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 92:50 RBU 100.0% UBU 100.0% 1072726016/8061945856 (13.3%) @0.0x, remaining 93:16 RBU 100.0% UBU 100.0% ^C/dev/pass0: flushing cache ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: DVD burner failure on FreeBSD: the LUN appears to be stuck
Hi,
i am not a skilled user of FreeBSD but have knowledge about
DVD burners and growisofs.
> growisofs is from dvd+rw-tools-7.1, which hasn't been updated from 2008.
That's the current release. It should be ok for DVD burning.
> :-? the LUN appears to be stuck writing LBA=7fe10h, keep retrying in 141ms
This obviously comes from growisofs.
growisofs_mmc.cpp has two occasions of that text. One would happen
when everything is written. So it is the other:
if (errcode==0x20408) // "LONG WRITE IN PROGRESS"
{ // Apparently only Pioneer units do this...
...
if (retries > (dao_toggle?768:192))
fprintf (stderr,":-? the LUN appears to be stuck "
"writing LBA=%xh, keep retrying in %dms\n",
lba,msecs),
The write run failed and the program assumes that the drive temporarily
went autistic. It does some calculations about how long the drive should
at most need to use up its buffered data. Depending on that it waits
for a short while
{ poll (NULL,0,msecs);
and if this happens extra suspiciously often, then it warns.
It seems that the retry cycle does never end as long as the
the program perceives sense code 2,04,08.
> Does this mean that the burner went bad? Or does
> this mean that there is some fault in the burner driver?
It would not be plausible if the FreeBSD passthrough services for
SCSI commands would produce a synthetic 2,04,08 reply. Most probably
it is the drive which issued that error indicator.
I test each release of libburn on FreeBSD-8 with a Samsung burner
and did not see such an effect yet.
Given the comments of Andy Polyakov in the code, the drive's
behavior could be a speciality of Pioneer. But i had 2,04,08
with Sony/Optiarc, too.
(That Optiarc drive performs proprietary commands of Lite-On
for qpxtool. So it can hardly be a disguised Pioneer ... i think.)
> Anybody is able to burn DVDs with the same/similar burner?
Try other media. Consider to get a new burner if the
problem persists. (I read about 18x DVD speed with that model.
So it must be more than five years old.)
Have a nice day :)
Thomas
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: src builds and STDERR
> Hello! > > On Fri, Mar 2, 2012 at 1:24 PM, Eygene Ryabinkin wrote: > > Thu, Mar 01, 2012 at 09:38:06AM -0800, Garrett Cooper wrote: > >> On Thu, Mar 1, 2012 at 9:01 AM, Chris Rees wrote: > >> > On 1 Mar 2012 16:31, "Garrett Cooper" wrote: > >> >> See: > >> >> http://lists.freebsd.org/pipermail/freebsd-current/2011-December/029852.html > >> >> . Why this patch is still not in FreeBSD proper, I do not know. > > [...] > >> bin/165589 -- thanks! > > > > The patch from mailing list was already committed to HEAD more than > > 2 weeks ago, > > http://svnweb.freebsd.org/base?view=revision&revision=231544 > > Don't see the MFC timeline, though. Max, any plans for MFC? > > JFYI: I MFC'ed Garret's patch to RELENG_9 several days ago. > > Max Ok, so ... Under 9.1-p3 RELEASE, upon world build failure, from STDERR, I still get just a: -- Error 1 -- So waht is going on?? Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UNIVERSE_TARGET doesn't seem to work
On 05/30/13 18:43, Navdeep Parhar wrote: > I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but > not this time) as part of my pre-commit checklist. It doesn't seem to > work after the switch to bmake. What am I missing? This on a system > at r251171 with nothing in make.conf or src.conf: > > # make -j12 universe UNIVERSE_TARGET=kernel-toolchain > --- universe_prologue --- > -- make universe started on Thu May 30 18:19:44 PDT 2013 > -- > `universe_amd64_prologue' was not built (made 0, flags 2009, type b01)! > `universe_arm_prologue' was not built (made 0, flags 2009, type b01)! > `universe_i386_prologue' was not built (made 0, flags 2009, type b01)! > `universe_ia64_prologue' was not built (made 0, flags 2009, type b01)! > `universe_mips_prologue' was not built (made 0, flags 2009, type b01)! > `universe_pc98_prologue' was not built (made 0, flags 2009, type b01)! > `universe_powerpc_prologue' was not built (made 0, flags 2009, type b01)! > `universe_sparc64_prologue' was not built (made 0, flags 2009, type b01)! > `universe_epilogue' was not built (made 1, flags 2009, type b01)! > `universe_epilogue' has .ORDER dependency against universe_amd64 (made 1, > flags 3009, type 301) > `universe_epilogue' has .ORDER dependency against universe_arm (made 1, > flags 3009, type 301) > `universe_epilogue' has .ORDER dependency against universe_i386 (made 1, > flags 3009, type 301) > `universe_epilogue' has .ORDER dependency against universe_ia64 (made 1, > flags 3009, type 301) > `universe_epilogue' has .ORDER dependency against universe_mips (made 1, > flags 3009, type 301) > `universe_epilogue' has .ORDER dependency against universe_pc98 (made 1, > flags 3009, type 301) > `universe_epilogue' has .ORDER dependency against universe_powerpc (made > 1, flags 3009, type 301) > `universe_epilogue' has .ORDER dependency against universe_sparc64 (made > 1, flags 3009, type 301) > > # make -j12 -DMAKE_JUST_KERNELS JFLAG=-j12 universe > (same result) It is the -j causing the problem. I tried with an empty /usr/obj too but that didn't help either. Does anyone know of a way around this? Building without -j is quite tedious. Navdeep ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UNIVERSE_TARGET doesn't seem to work
On 3 June 2013 23:13, Navdeep Parhar wrote: > On 05/30/13 18:43, Navdeep Parhar wrote: >> I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but >> not this time) as part of my pre-commit checklist. It doesn't seem to >> work after the switch to bmake. What am I missing? This on a system >> at r251171 with nothing in make.conf or src.conf: >> >> # make -j12 universe UNIVERSE_TARGET=kernel-toolchain >> --- universe_prologue --- >> -- > make universe started on Thu May 30 18:19:44 PDT 2013 >> -- >> `universe_amd64_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_arm_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_i386_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_ia64_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_mips_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_pc98_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_powerpc_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_sparc64_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_epilogue' was not built (made 1, flags 2009, type b01)! >> `universe_epilogue' has .ORDER dependency against universe_amd64 (made >> 1, flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_arm (made 1, >> flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_i386 (made 1, >> flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_ia64 (made 1, >> flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_mips (made 1, >> flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_pc98 (made 1, >> flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_powerpc (made >> 1, flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_sparc64 (made >> 1, flags 3009, type 301) >> >> # make -j12 -DMAKE_JUST_KERNELS JFLAG=-j12 universe >> (same result) > > It is the -j causing the problem. I tried with an empty /usr/obj too > but that didn't help either. Does anyone know of a way around this? > Building without -j is quite tedious. try the parameter JFLAG ? from man build: JFLAG Pass the value of this variable to each make(1) invo- cation used to build worlds and kernels. This can be used to enable multiple jobs within a single architec- ture's build while still building each architecture serially. -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UNIVERSE_TARGET doesn't seem to work
On Mon, Jun 03, 2013 at 02:13:38PM -0700, Navdeep Parhar wrote: > On 05/30/13 18:43, Navdeep Parhar wrote: > > I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but > > not this time) as part of my pre-commit checklist. It doesn't seem to > > work after the switch to bmake. What am I missing? This on a system > > at r251171 with nothing in make.conf or src.conf: > > > > # make -j12 universe UNIVERSE_TARGET=kernel-toolchain > > --- universe_prologue --- > > -- > make universe started on Thu May 30 18:19:44 PDT 2013 > > -- > > `universe_amd64_prologue' was not built (made 0, flags 2009, type b01)! > > `universe_arm_prologue' was not built (made 0, flags 2009, type b01)! > > `universe_i386_prologue' was not built (made 0, flags 2009, type b01)! > > `universe_ia64_prologue' was not built (made 0, flags 2009, type b01)! > > `universe_mips_prologue' was not built (made 0, flags 2009, type b01)! > > `universe_pc98_prologue' was not built (made 0, flags 2009, type b01)! > > `universe_powerpc_prologue' was not built (made 0, flags 2009, type > > b01)! > > `universe_sparc64_prologue' was not built (made 0, flags 2009, type > > b01)! > > `universe_epilogue' was not built (made 1, flags 2009, type b01)! > > `universe_epilogue' has .ORDER dependency against universe_amd64 (made > > 1, flags 3009, type 301) > > `universe_epilogue' has .ORDER dependency against universe_arm (made 1, > > flags 3009, type 301) > > `universe_epilogue' has .ORDER dependency against universe_i386 (made > > 1, flags 3009, type 301) > > `universe_epilogue' has .ORDER dependency against universe_ia64 (made > > 1, flags 3009, type 301) > > `universe_epilogue' has .ORDER dependency against universe_mips (made > > 1, flags 3009, type 301) > > `universe_epilogue' has .ORDER dependency against universe_pc98 (made > > 1, flags 3009, type 301) > > `universe_epilogue' has .ORDER dependency against universe_powerpc > > (made 1, flags 3009, type 301) > > `universe_epilogue' has .ORDER dependency against universe_sparc64 > > (made 1, flags 3009, type 301) > > > > # make -j12 -DMAKE_JUST_KERNELS JFLAG=-j12 universe > > (same result) > > It is the -j causing the problem. I tried with an empty /usr/obj too > but that didn't help either. Does anyone know of a way around this? > Building without -j is quite tedious. You can try passing 'JFLAG=-j12' to the make universe invocation. It's not the same in that each target is built with -j12 rather rather than building 12 targets at once. But it lets me finish a make universe overnight on my laptop. -Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UNIVERSE_TARGET doesn't seem to work
On 06/03/13 14:20, Eitan Adler wrote: > On 3 June 2013 23:13, Navdeep Parhar wrote: >> On 05/30/13 18:43, Navdeep Parhar wrote: >>> I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but >>> not this time) as part of my pre-commit checklist. It doesn't seem to >>> work after the switch to bmake. What am I missing? This on a system >>> at r251171 with nothing in make.conf or src.conf: >>> >>> # make -j12 universe UNIVERSE_TARGET=kernel-toolchain >>> --- universe_prologue --- >>> -- >> make universe started on Thu May 30 18:19:44 PDT 2013 >>> -- >>> `universe_amd64_prologue' was not built (made 0, flags 2009, type b01)! >>> `universe_arm_prologue' was not built (made 0, flags 2009, type b01)! >>> `universe_i386_prologue' was not built (made 0, flags 2009, type b01)! >>> `universe_ia64_prologue' was not built (made 0, flags 2009, type b01)! >>> `universe_mips_prologue' was not built (made 0, flags 2009, type b01)! >>> `universe_pc98_prologue' was not built (made 0, flags 2009, type b01)! >>> `universe_powerpc_prologue' was not built (made 0, flags 2009, type >>> b01)! >>> `universe_sparc64_prologue' was not built (made 0, flags 2009, type >>> b01)! >>> `universe_epilogue' was not built (made 1, flags 2009, type b01)! >>> `universe_epilogue' has .ORDER dependency against universe_amd64 (made >>> 1, flags 3009, type 301) >>> `universe_epilogue' has .ORDER dependency against universe_arm (made 1, >>> flags 3009, type 301) >>> `universe_epilogue' has .ORDER dependency against universe_i386 (made >>> 1, flags 3009, type 301) >>> `universe_epilogue' has .ORDER dependency against universe_ia64 (made >>> 1, flags 3009, type 301) >>> `universe_epilogue' has .ORDER dependency against universe_mips (made >>> 1, flags 3009, type 301) >>> `universe_epilogue' has .ORDER dependency against universe_pc98 (made >>> 1, flags 3009, type 301) >>> `universe_epilogue' has .ORDER dependency against universe_powerpc >>> (made 1, flags 3009, type 301) >>> `universe_epilogue' has .ORDER dependency against universe_sparc64 >>> (made 1, flags 3009, type 301) >>> >>> # make -j12 -DMAKE_JUST_KERNELS JFLAG=-j12 universe >>> (same result) >> >> It is the -j causing the problem. I tried with an empty /usr/obj too >> but that didn't help either. Does anyone know of a way around this? >> Building without -j is quite tedious. > > try the parameter JFLAG ? > > from man build: > JFLAG Pass the value of this variable to each make(1) invo- > cation used to build worlds and kernels. This can be > used to enable multiple jobs within a single architec- > ture's build while still building each architecture > serially. But I want to build the architectures in parallel and run multiple jobs within each architecture in parallel as well (which is why you see both -j12 and JFLAG=-j12 in the command that I posted above). It used to work till fairly recently. Regards, Navdeep ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UNIVERSE_TARGET doesn't seem to work
On Mon, 3 Jun 2013 14:13:38 -0700, Navdeep Parhar writes: >On 05/30/13 18:43, Navdeep Parhar wrote: >> I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but >> not this time) as part of my pre-commit checklist. It doesn't seem to >> work after the switch to bmake. What am I missing? This on a system >> at r251171 with nothing in make.conf or src.conf: Taking a look. The error usually means there's an explicit dependency that conflicts with .ORDER >> >> # make -j12 universe UNIVERSE_TARGET=kernel-toolchain >> --- universe_prologue --- >> -- > make universe started on Thu May 30 18:19:44 PDT 2013 >> -- >> `universe_amd64_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_arm_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_i386_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_ia64_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_mips_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_pc98_prologue' was not built (made 0, flags 2009, type b01)! >> `universe_powerpc_prologue' was not built (made 0, flags 2009, type b01) >! >> `universe_sparc64_prologue' was not built (made 0, flags 2009, type b01) >! >> `universe_epilogue' was not built (made 1, flags 2009, type b01)! >> `universe_epilogue' has .ORDER dependency against universe_amd64 (made 1 >, flags 3009, type 301) >> `universe_epilogue' has .ORDER dependency against universe_arm (made 1, >flags 3009, type 301) >It is the -j causing the problem. I tried with an empty /usr/obj too Yes, because .ORDER only matters in jobs mode. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: UNIVERSE_TARGET doesn't seem to work
On Mon, 3 Jun 2013 14:13:38 -0700, Navdeep Parhar writes:
>On 05/30/13 18:43, Navdeep Parhar wrote:
>> I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but
>> not this time) as part of my pre-commit checklist. It doesn't seem to
>> work after the switch to bmake. What am I missing? This on a system
>> at r251171 with nothing in make.conf or src.conf:
>>
>> # make -j12 universe UNIVERSE_TARGET=kernel-toolchain
>> --- universe_prologue ---
So not so much conflicting dependencies, but bmake seems to not like
.ORDER and explicit dependencies that effectively say the same thing.
That is since there is an explicit dependency:
universe_${target}: universe_${target}_prologue
it shouldn't be necessary to also express that in the .ORDER
This is probably a bug, but identifying exactly where and a fix could
take a while.
Moving the .ORDER out of the loop like:
@@ -373,9 +373,10 @@
.if defined(DOING_TINDERBOX)
@rm -f ${FAILFILE}
.endif
+.ORDER: universe_prologue upgrade_checks universe_targets universe_epilogue
.for target in ${TARGETS}
universe: universe_${target}
-.ORDER: universe_prologue upgrade_checks universe_${target}_prologue
universe_${target} universe_epilogue
+universe_targets: universe_${target}
universe_${target}: universe_${target}_prologue
universe_${target}_prologue:
@echo ">> ${target} started on `LC_ALL=C date`"
would seem to make sense, but fmake runs universe_epilogue too early
(which is also a bug).
Thus the simplest patch which avoids an error and works for both
bmake and fmake is:
Index: Makefile
===
--- Makefile(revision 250971)
+++ Makefile(working copy)
@@ -375,7 +375,7 @@
.endif
.for target in ${TARGETS}
universe: universe_${target}
-.ORDER: universe_prologue upgrade_checks universe_${target}_prologue
universe_${target} universe_epilogue
+.ORDER: universe_prologue upgrade_checks universe_${target} universe_epilogue
universe_${target}: universe_${target}_prologue
universe_${target}_prologue:
@echo ">> ${target} started on `LC_ALL=C date`"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
pw
NetZero now offers 4G mobile broadband. Sign up now. http://www.netzero.net/?refcd=NZINTISP0512T4GOUT1 I have 2 FreeBSD systems (they are using versions 4.3 and 4.7 of the FreeBSD Operating System) that I have not used for a long time, and I have forgotten their passwords. I have information on these systems that I want to retrieve but I have not been able to log into these Systems. My problem was put on the internet several years ago and the usual ways of getting into the systems (basically by being the operator) were suggested and tried, unsuccressfully. A friend and I discussed my problem and he suggested that I zero out the root password so that I can get in as rooy (to set a new password and then continue operating as root). Does the FreeBSD community have a program (either on a floppy or a CD ROM, preferably the latter) that can do this? If not, I suggest that you write one that would work with all the (formats of) password files that have ever been used. If it can determine the format of password files just by examining them, that would be fine. If it can't, then it should ask the user in which version of the FreeBSD Operating System the password file was used, try to verify it by the structure of the password file and if it is verified make a copy of the password file (in case something goes wrong, so that the system can be restored to its original condition and so undo anything that this program has done), and zero out the root password. After this is done, one could log in as root to set the root password and afterwards (as root) set other user passwords. Operating Systems that have ever been run. You could set it up to look ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pw
Boot a live cd and mount the rootfs and replace the passwd files with some preconfigured ones. It's really not that hard. -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jun 4, 2013, at 1:47, "gs_stol...@juno.com" wrote: > > > > NetZero now offers 4G mobile broadband. Sign up now. > http://www.netzero.net/?refcd=NZINTISP0512T4GOUT1 > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" smime.p7s Description: S/MIME cryptographic signature
Re: pw
I guess I could have been more clear about this as well... Files you need ( pre-prepped ): /etc/passwd /etc/master.passwd /etc/pwd.db - or - Use /usr/bin/vi following up with /usr/sbin/pwd_mkdb - or - /usr/sbin/vipw Either which way there is a man page for each and recovering a old system like that with even newer live media is not that hard of a task considering you don't need to do anything with the passwd files at all in order to mount any of the slices and pull whatever it is off from it directly. PS: the utilities that are there have already been written. You have just wasted several years just not looking for them or using them correctly and would suggest that you write something if these are not satisfyingly straight forward enough for you. Several years of no answer might just be the answer that was right there before you in the first place. #AH -- Jason Hellenthal Inbox: jhellent...@dataix.net Voice: +1 (616) 953-0176 JJH48-ARIN On Jun 4, 2013, at 1:47, "gs_stol...@juno.com" wrote: > > > > NetZero now offers 4G mobile broadband. Sign up now. > http://www.netzero.net/?refcd=NZINTISP0512T4GOUT1 > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" smime.p7s Description: S/MIME cryptographic signature
Re: pw
> I guess I could have been more clear about this as well... > > Files you need ( pre-prepped ): > /etc/passwd > /etc/master.passwd > /etc/pwd.db > > - or - > Use /usr/bin/vi following up with /usr/sbin/pwd_mkdb > > - or - > > /usr/sbin/vipw > > Either which way there is a man page for each and recovering a old system > like that with even newer live media is not that hard of a task considering > you don't need to do anything with the passwd files at all in order to mount > any of the slices and pull whatever it is off from it directly. > > PS: the utilities that are there have already been written. You have just > wasted several years just not looking for them or using them correctly and > would suggest that you write something if these are not satisfyingly straight > forward enough for you. > > Several years of no answer might just be the answer that was right there > before you in the first place. > > #AH > > -- > Jason Hellenthal > Inbox: jhellent...@dataix.net Fastest way is to simply drop into a single user mode and just pick a shell. Now you are THE root. (By default, entering into single user mode, doesn't prompt for password) mount / RW and # passwd (it exists on 4.x?) Volila! Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
