Bug #875

remounting of root rw causes system unbootability in certain circumstances

Added by Wolf Noble over 3 years ago. Updated about 1 year ago.

Status:ClosedStart date:
Priority:Nice to haveDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Seen in:

Description

My environment:
hp proliant microserver
http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/15351-15351-4237916-4237918-4237917-4248009.html
usb flash:
Sandisk Cruzer 4G (from costco) SDCZ36-004G
http://www.amazon.com/SanDisk-Cruzer-Flash-Drive-SDCZ36-004G-A11/dp/B001T9EYFI

steps to duplicate behavior

install / upgrade
login as root
mount -urw /
mount -ur /
reboot

end result:

F1 FreeBSD
F2 FreeBSD
F5 Drive 1
F6 PXE

Boot: F1

\

it will happily sit there forever. The only solution I've found is reupgrading via CD.. which is.. less than optimal.

I have tried this with multiple jumpdrives of the same type, however these are all i happen to have, so I didn't try something else.

I first noticed this behavior in the 8.01 RCs... it's still there. it's LIKELY something upstream, but I don't know.

I'm happy to help debug this but I don't really know where to start.

History

#1 Updated by Garrett Cooper over 3 years ago

It's potentially breaking assumptions when rebooting and/or data is being written out to flash. I'll look at this more carefully sometime later on this week, but if you have any screenshots at reboot, that would help.

#2 Updated by Garrett Cooper over 3 years ago

Could you please also do the following from the LiveCD (assuming your machine's still in a failed state) and provide screenshots?

gpart list
dd if=/dev/<your-flash-drive-dev-goes-here> count=2 | hexdump -C

(I have to check and see whether or not hexdump is available on the install CD)

The above method is what we need to track down "who's on first".

#3 Updated by Wolf Noble over 3 years ago

$ su -
Password:
[root@freenas] ~# mount -urw /
[root@freenas] ~# mount -ur /
[root@freenas] ~# mount
/dev/ufs/FreeNASs1a on / (ufs, local, read-only, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/md0 on /etc (ufs, local)
/dev/md1 on /mnt (ufs, local)
/dev/md2 on /var (ufs, local)
/dev/ufs/FreeNASs4 on /data (ufs, local, noatime, soft-updates)
Tank on /mnt/Tank (zfs, local)
Tank/Art on /mnt/Tank/Art (zfs, local)
Tank/Backup on /mnt/Tank/Backup (zfs, local, noatime)
Tank/Documentation on /mnt/Tank/Documentation (zfs, local, noatime)
Tank/Drivers on /mnt/Tank/Drivers (zfs, local, noatime)
Tank/Media on /mnt/Tank/Media (zfs, local)
Tank/OSImages on /mnt/Tank/OSImages (zfs, local, noatime)
Tank/Share on /mnt/Tank/Share (zfs, local, noatime)
Tank/Software on /mnt/Tank/Software (zfs, local, noatime)
Tank/Store on /mnt/Tank/Store (zfs, local, noatime)
Tank/bsdjail on /mnt/Tank/bsdjail (zfs, local)
Tank/bsdlocal on /mnt/Tank/bsdlocal (zfs, NFS exported, local)
Tank/bsdports on /mnt/Tank/bsdports (zfs, NFS exported, local)
Tank/bsdroot on /mnt/Tank/bsdroot (zfs, local)
Tank/distfiles on /mnt/Tank/distfiles (zfs, NFS exported, local)
Tank/homedirs on /mnt/Tank/homedirs (zfs, NFS exported, local)
/dev/md3 on /var/tmp/.cache (ufs, local, soft-updates)
[root@freenas] ~# reboot
Connection to 10.12.3.7 closed by remote host.
Connection to 10.12.3.7 closed.

on console post reboot:

F1 FreeBSD
F2 FreeBSD
F5 Drive 1
F6 PXE

Boot: F1
\

boot from 8.01 rel iso option 4 (single user):
gpart list >/tmp/list
dd if=/dev/da0 count=2 of=/tmp/ddout
mkdir /mnt/foo
(insert old backup usb drive which used to have fn8)
mount /dev/da1s1a /mnt/foo
cp /tmp/ddout /mnt/foo/ddout
cp /tmp/list /mnt/foo/list
umount /mnt/foo
reboot
upgrade installation (aka repair the brokenness)
boot into fixed FN8 install
mkdir /tmp/test
mount /dev/da1s1a /tmp/test

[root@freenas] ~# cat /tmp/test/ddout |hexdump -C
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| *
00000400

cat /tmp/test/list

Geom name: da0
state: OK
fwheads: 255
fwsectors: 63
last: 7813070
first: 63
entries: 4
scheme: MBR
Providers:
1. Name: da0s1
Mediasize: 988291584 (943M)
Sectorsize: 512
Mode: r0w0e0
attrib: active
rawtype: 165
length: 988291584
offset: 32256
type: freebsd
index: 1
end: 1930319
start: 63
2. Name: da0s2
Mediasize: 988291584 (943M)
Sectorsize: 512
Mode: r0w0e0
rawtype: 165
length: 988291584
offset: 988356096
type: freebsd
index: 2
end: 3860639
start: 1930383
3. Name: da0s3
Mediasize: 1548288 (1.5M)
Sectorsize: 512
Mode: r0w0e0
rawtype: 165
length: 1548288
offset: 1976647680
type: freebsd
index: 3
end: 3863663
start: 3860640
4. Name: da0s4
Mediasize: 21159936 (20M)
Sectorsize: 512
Mode: r0w0e0
rawtype: 165
length: 21159936
offset: 1978195968
type: freebsd
index: 4
end: 3904991
start: 3863664
Consumers:
1. Name: da0
Mediasize: 4000317440 (3.7G)
Sectorsize: 512
Mode: r0w0e0

Geom name: da0s1
state: OK
fwheads: 255
fwsectors: 63
last: 1930256
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: da0s1a
Mediasize: 988283392 (943M)
Sectorsize: 512
Mode: r0w0e0
rawtype: 0
length: 988283392
offset: 8192
type: !0
index: 1
end: 1930256
start: 16
Consumers:
1. Name: da0s1
Mediasize: 988291584 (943M)
Sectorsize: 512
Mode: r0w0e0

Geom name: ada0
state: OK
fwheads: 16
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada0p1
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 7e23cdb0-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1073741824
offset: 65536
type: freebsd-swap
index: 1
end: 2097279
start: 128
2. Name: ada0p2
Mediasize: 1999325109760 (1.8T)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 7e385e6e-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1999325109760
offset: 1073807360
type: freebsd-zfs
index: 2
end: 3907029134
start: 2097280
Consumers:
1. Name: ada0
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Mode: r0w0e0

Geom name: ada1
state: OK
fwheads: 16
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada1p1
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 7f48aaf7-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1073741824
offset: 65536
type: freebsd-swap
index: 1
end: 2097279
start: 128
2. Name: ada1p2
Mediasize: 1999325109760 (1.8T)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 7f5e7494-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1999325109760
offset: 1073807360
type: freebsd-zfs
index: 2
end: 3907029134
start: 2097280
Consumers:
1. Name: ada1
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Mode: r0w0e0

Geom name: ada2
state: OK
fwheads: 16
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada2p1
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 8070b3db-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1073741824
offset: 65536
type: freebsd-swap
index: 1
end: 2097279
start: 128
2. Name: ada2p2
Mediasize: 1999325109760 (1.8T)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 80853879-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1999325109760
offset: 1073807360
type: freebsd-zfs
index: 2
end: 3907029134
start: 2097280
Consumers:
1. Name: ada2
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Mode: r0w0e0

Geom name: ada3
state: OK
fwheads: 16
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada3p1
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 8196677c-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1073741824
offset: 65536
type: freebsd-swap
index: 1
end: 2097279
start: 128
2. Name: ada3p2
Mediasize: 1999325109760 (1.8T)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 81ac32fc-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1999325109760
offset: 1073807360
type: freebsd-zfs
index: 2
end: 3907029134
start: 2097280
Consumers:
1. Name: ada3
Mediasize: 2000398934016 (1.8T)
Sectorsize: 512
Mode: r0w0e0

Geom name: ada4
state: OK
fwheads: 16
fwsectors: 63
last: 125045390
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada4p1
Mediasize: 1073741824 (1.0G)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 82b10668-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 1073741824
offset: 65536
type: freebsd-swap
index: 1
end: 2097279
start: 128
2. Name: ada4p2
Mediasize: 62949432832 (59G)
Sectorsize: 512
Mode: r0w0e0
rawuuid: 82b51ebb-c056-11e0-86b4-d485646a6bfd
rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
label: (null)
length: 62949432832
offset: 1073807360
type: freebsd-zfs
index: 2
end: 125045390
start: 2097280
Consumers:
1. Name: ada4
Mediasize: 64023257088 (60G)
Sectorsize: 512

#4 Updated by Wolf Noble over 3 years ago

Is there anything else I can provide to help discern the cause of this? I'd like to be able to tweak my install a bit, but seeing as anytime I modify the filesystem I have to reinstall on next reboot, it's something of a moot point.

#5 Updated by Wolf Noble over 3 years ago

I know this seems minor, but it'd really be helpful to figure out what's going on here; or at the bare minimum, figure out a way to recover/repair the bootability of the system so that I can make some small modifications to the FN install

#6 Updated by Wolf Noble over 3 years ago

I can confirm I'm still running into this in 8.0.3-multimedia. I know this seems like a minor edge case. It'd still be really helpful to figure out what's going on here; or at the bare minimum, figure out a way to recover/repair the bootability of the system so that I can make some small modifications to the FN install.

What additional information can I provide to help in the diagnosis of this (admittedly edge case) problem?

#7 Updated by Garrett Cooper over 3 years ago

If you hit a key on the keyboard when the issue occurs, does it continue to boot or hang?

#8 Updated by Wolf Noble over 3 years ago

as mentioned in IRC; hitting a key on the keyboard at that point does nothing. I've uploaded the DB as requested... Looking forward to figuring this out. Thanks in advance for the help.

#9 Updated by Garrett Cooper over 3 years ago

Working on the last of the believed filesystem metadata robustness fixes for 8.0.4-BETA2 and the Cruzer from Amazon is on its way for the final verification step.

#10 Updated by Garrett Cooper over 3 years ago

Looking at recent observations and this dd output (first run is with the Cruzer, second run is with PQI U172P)...

$ xzcat obj.amd64/FreeNAS-8.2.1-ALPHA-r10110M-x64.img.xz | sudo dd bs=10m of=/dev/da0
...
2000000000 bytes transferred in 2064.889037 secs (968575 bytes/sec)

$ xzcat obj.amd64/FreeNAS-8.2.1-ALPHA-r10110M-x64.img.xz | sudo dd bs=10m of=/dev/da0

...

2000000000 bytes transferred in 324.678048 secs (6159948 bytes/sec)

... my gut says that the issues occurring here with the Sandisk media are based on two different issues:

1. The device is potentially lying when sync(2) is run.
2. The root filesystem is getting corrupted when writing back to the device (this has been the bane of filesystem developers for some time, even with hard drives).

The way FreeNAS 8.x was/is designed following the nanobsd model, /cfg (s3) should be used for persistent configuration data that isn't touched that often and /data (s4) should be used for persistent data that is changed more often.

In FreeNAS 8.x /cfg isn't used and as time evolved, some of the changes put in place to modify the root filesystem became unnecessary. Many of the in-place modifications have been removed as part of recent commits to the rc.d scripts, and other preventative measures have been added to avoid this race; more modifications can be added if warranted (e.g. adding -o sync to mount in stability critical scenarios, or shuffling files off to /cfg as needed).

Based on the above results, I do not recommend the San Cruzer devices for use with UFS. You will most likely be better off purchasing ATP, PQI, or HDD/SSD media. The way that things are done with FreeNAS 8.x today aren't correct per embedded system design I've dealt with in the past (read an image once, do not touch it ever, write back to permanent device only in the event that an upgrade is required).

As I've said in less public forums, "the system should be using an mfsroot instead of dealing with the raw device". This is the way that legacy did it, this is the way that I've done things before in some of the system I've designed based on advice from my previous mentors, and it should be the way that things are done in FreeNAS 8.x.

#11 Updated by Wolf Noble over 3 years ago

I purchased an ATP petito 4G usb drive and installed the 8.0.3 RC on it.
I booted from the cd again, this time also including my original usb stick. I selected shell vs installing again
da0 = ATP
da1 = Sandisk

I then copied my config over:

mkdir /orig; mkdir /new
mount /dev/da1s4 /orig; mount /dev/da0s4 /new;
cd /orig; tar cpf - . |(cd /new && tar xpf -)
cd /
umount /orig
umount /new

I then rebooted from the cd, removing my original media. I reinstalled and upgraded.

at this point I should have a good copy of the system..

boot into FN, choose the shell option from console:
mount -urw / ; touch /writablefoo ; mount -ur /; reboot

I experience the same behavior on 8.0.3RC1 with the ATP media that I did with the sandisk media.

I tried upgrading with the just released 8.0.4RC1 media...
it upgraded the install fine. went on and booted into the db upgrade boot and did it's thing, subsequently rebooted.

at that point it stopped booting shortly after trying to load the kernel. the last thing presented on the screen is :
Loading /boot/defaults/loader.conf |

(the ascii graphic does spin a bit before hanging here, but it doesn't display the kernel or the usual text= data= syms= ... just hangs)

So my impression here is that there's still something that I'm missing.

How can I additionally help diagnose this?

#12 Updated by Wolf Noble over 3 years ago

I tried upgrading with the just released 8.0.4RC1 media...
it upgraded the install fine. went on and booted into the db upgrade boot and did it's thing, subsequently rebooted.
at that point it stopped booting shortly after trying to load the kernel. the last thing presented on the screen is :
Loading /boot/defaults/loader.conf |
(the ascii graphic does spin a bit before hanging here, but it doesn't display the kernel or the usual text= data= syms= ... just hangs)
So my impression here is that there's still something that I'm missing.
How can I additionally help diagnose this?

FreeBSD/x86 bootstrap loader, Revision 1.1
(, Thu Feb 23 16:32:42 PST 2012)
Loading /boot/defaults/loader.conf |
... zzzZzzzZzzZZzzZZZZZZ

#13 Updated by Garrett Cooper about 3 years ago

Looks like the metadata was bad on the diskimage I received (in particular the superblock was busted based on my reading of fsck_ffs):

[root@bayonetta /scratch]# fsck -t ufs -y /dev/md1s1a
** /dev/md1s1a
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
SUMMARY INFORMATION BAD
SALVAGE? yes

25278 files, 854969 used, 1042837 free (1109 frags, 130216 blocks, 0.1% fragmentation)

***** FILE SYSTEM IS CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****

After fsck'ing the filesystem things look ok from a UFS perspective.

[root@bayonetta /scratch]# fsck -t ufs -y /dev/md1s1a
** /dev/md1s1a
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
25278 files, 854969 used, 1042837 free (1109 frags, 130216 blocks, 0.1% fragmentation)

***** FILE SYSTEM IS CLEAN *****

The images produced by the build system on 9.x boxes (at least) exhibit the same/similar behavior:

# mdconfig -a -f /scratch/f/trunk/os-base/amd64/FreeNAS-8.2.1-ALPHA-r10563M-x64.GUI_Upgrade
md2
[root@bayonetta /usr/src/sbin/fsck_ffs]# mount /dev/md2
md2   md2a
[root@bayonetta /usr/src/sbin/fsck_ffs]# mount /dev/md2
md2   md2a
[root@bayonetta /usr/src/sbin/fsck_ffs]# mkdir /mnt2; mount /dev/md2a /mnt2
[root@bayonetta /usr/src/sbin/fsck_ffs]# mkdir /mnt2; mount /dev/md2a
mount: /dev/md2a: unknown special file or file system
[root@bayonetta /usr/src/sbin/fsck_ffs]# tunefs -p /dev/md2a
tunefs: POSIX.1e ACLs: (-a)                                disabled
tunefs: NFSv4 ACLs: (-N)                                   disabled
tunefs: MAC multilabel: (-l)                               disabled
tunefs: soft updates: (-n)                                 enabled
tunefs: soft update journaling: (-j)                       disabled
tunefs: gjournal: (-J)                                     disabled
tunefs: trim: (-t)                                         disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  512
tunefs: average file size: (-f)                            16384
tunefs: average number of files in a directory: (-s)       64
tunefs: minimum percentage of free space: (-m)             8%
tunefs: optimization preference: (-o)                      time
tunefs: volume label: (-L)                                 [[FreeNASs]]1a
[root@bayonetta /usr/src/sbin/fsck_ffs]# fsck -t ufs /dev/md2a
[root@bayonetta /usr/src/sbin/fsck_ffs]# fsck -t ufs /dev/md2a
** /dev/md2a
** Last Mounted on /scratch/f/trunk/os-base/amd64/_.mnt
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
SUMMARY INFORMATION BAD
SALVAGE? [yn] y

21526 files, 712765 used, 1185041 free (1049 frags, 147999 blocks, 0.1% fragmentation)

***** FILE SYSTEM IS CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****
[root@bayonetta /usr/src/sbin/fsck_ffs]# uname -a
[[FreeBSD]] bayonetta.local 9.0-STABLE [[FreeBSD]] 9.0-STABLE #6 r231963M: Mon Feb 20 23:15:28 PST 2012     gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA  amd64

It's not confidence inspiring that this is happening to images right after they're produced via nanobsd (no mangling occurs after create_i386_diskimage other than the filename and compression). I'm going to add some hacks to the build system to try and ameliorates things (force fsck -y the images), but we need to figure out the root cause and correlate whether or not this is a real issue, a smoking gun, or a red herring.

It would also help to determine why this case (if it's indeed the underlying problem) is a problem on loiosh's machine(s), but not other machines.

More info follows...

[root@bayonetta /usr/src/sbin/fsck_ffs]# gpart status md1
 Name  Status  Components
md1s1      OK  md1
md1s2      OK  md1
md1s3      OK  md1
md1s4      OK  md1
[root@bayonetta /usr/src/sbin/fsck_ffs]# gpart list md1
Geom name: md1
modified: false
state: OK
fwheads: 128
fwsectors: 63
last: 7837695
first: 1
entries: 4
scheme: MBR
Providers:
1. Name: md1s1
   Mediasize: 988291584 (942M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 32256
   Mode: r0w0e0
   attrib: active
   rawtype: 165
   length: 988291584
   offset: 32256
   type: freebsd
   index: 1
   end: 1930319
   start: 63
2. Name: md1s2
   Mediasize: 988291584 (942M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 988356096
   Mode: r0w0e0
   rawtype: 165
   length: 988291584
   offset: 988356096
   type: freebsd
   index: 2
   end: 3860639
   start: 1930383
3. Name: md1s3
   Mediasize: 1548288 (1.5M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1976647680
   Mode: r0w0e0
   rawtype: 165
   length: 1548288
   offset: 1976647680
   type: freebsd
   index: 3
   end: 3863663
   start: 3860640
4. Name: md1s4
   Mediasize: 21159936 (20M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1978195968
   Mode: r0w0e0
   rawtype: 165
   length: 21159936
   offset: 1978195968
   type: freebsd
   index: 4
   end: 3904991
   start: 3863664
Consumers:
1. Name: md1
   Mediasize: 4012900352 (3.8G)
   Sectorsize: 512
   Mode: r0w0e0
[root@bayonetta /usr/src/sbin/fsck_ffs]# gpart list md2
Geom name: md2
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 1930256
first: 0
entries: 8
scheme: BSD
Providers:
1. Name: md2a
   Mediasize: 988283392 (942M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 8192
   Mode: r0w0e0
   rawtype: 0
   length: 988283392
   offset: 8192
   type: !0
   index: 1
   end: 1930256
   start: 16
Consumers:
1. Name: md2
   Mediasize: 988291584 (942M)
   Sectorsize: 512
   Mode: r0w0e0

[root@bayonetta /usr/src/sbin/fsck_ffs]# gpart status md2
Name  Status  Components
md2a      OK  md2

#14 Updated by Wolf Noble about 3 years ago

Any updates here? wheel squeak

#15 Updated by Wolf Noble almost 3 years ago

So I just downloaded the 8.04 multimedia image.
I installed it onto a fresh memory stick
I let it boot up as freenas.local

I added my config to it via the web ui

it rebooted. went on and performed the db upgrade boot and did it's thing, subsequently rebooted.
at that point it stopped booting shortly after trying to load the kernel. the last thing presented on the screen is :
Loading /boot/defaults/loader.conf |
(the ascii graphic does spin a bit before hanging here, but it doesn't display the kernel or the usual text= data= syms= ... just hangs)
So my impression here is that there's still something that I'm missing.
How can I additionally help diagnose this?
FreeBSD/x86 bootstrap loader, Revision 1.1
(root@…, Thu Feb 23 16:32:42 PST 2012)
Loading /boot/defaults/loader.conf |
... zzzZzzzZzzZZzzZZZZZZ

(this data is scraped from the previous post of mine. the behavior is the same although the date listed is different)

I'm going to do a fresh install and just copy the config that it updated back onto the /data partition and see if that will stick... otherwise, this is really making freenas somewhat useless... how can I maintain a system that cannot be upgraded and subsequently reboot?

#16 Updated by Wolf Noble almost 3 years ago

I managed to get a fresh install of 8.04 to boot, but I still experience the same issue.

Does anyone have any input on this? is there anything I can do to help demonstrate this issue?

#17 Updated by Wolf Noble almost 3 years ago

I spent some time last night trying everything I could....

disabling various CPU options in the bios did nothing.
forcing the bios to treat the usb device as a floppy, cdrom, or hdd didn't have any perceived change either.
behavior is the same across internal, front, back usb ports.
behavior is the same with the ATP usb drive gcooper recommended, and with a sandisk usb stick I have been using.

any ideas would be really appreciated, I'd love to be able to reboot my nas without having to reinstall it.

F1 FreeBSD
F2 FreeBSD
F5 Drive 1
F6 PXE
Boot: F1
\

isn't the greatest thing to look at when my nas tries to boot :)

#18 Updated by Jordan Hubbard about 1 year ago

  • Status changed from Unscreened to Closed
  • Seen in set to

Closing as 💀🐞.

Also available in: Atom PDF