sysinstall alpha problems...
I updated to 5.0-current using the . tag because I wanted SMP support for our development AlphaServer 1200 that was otherwise gathering dust. I added some new disks and wanted to do a sysinstall to label and newfs them. So running /usr/sbin/sysinstall built from the sources of today sysinstall simply core dumps on the device probe section. I tried adding a -g to cflags in its makefile but couldn't coax gdb into spitting out anything more useful. Here is what I get: Probing devices, please wait (this can take a while)...Segmentation fault (core dumped) Based on the fact it seems to be dying inside a call to strtoul I'm guessing its integer size related so it probably won't show on ix86. If someone can direct me further I can do more to help in debugging this... alpha# gdb /usr/sbin/sysinstall -c sysinstall.core GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as alpha-undermydesk-freebsd...(no debugging symbols found)... Core was generated by `sysinstall'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libdialog.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libdialog.so.4 Reading symbols from /usr/lib/libncurses.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libncurses.so.5 Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libutil.so.3 Reading symbols from /usr/lib/libftpio.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libftpio.so.5 Reading symbols from /usr/lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so.5 Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x160242644 in strtoul () from /usr/lib/libc.so.5 (gdb) bt #0 0x160242644 in strtoul () from /usr/lib/libc.so.5 (gdb) Here is a little system info: FreeBSD alpha.interchange.ca 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Thu Oct 31 01:54:22 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOATANCHOR alpha alpha# gcc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) This system was installed as a 4.7-alpha and then upgraded via a cvsup and makeworld/installworld. -Michael _ http://fastmail.ca/ - Fast Secure Web Email for Canadians
Re: sysinstall alpha problems...
Ok, first make sure that your machine is running a -current kernel. FreeBSD 5.0-CURRENT #0: Thu Oct 31 01:54:22 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOATANCHOR Preloaded elf kernel /boot/kernel/kernel at 0xfc69a000. AlphaServer 4100 AlphaServer 1200 5/533 4MB, 531MHz 8192 byte page size, 2 processors. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1BWX OSF PAL rev: 0x4000200020117 real memory = 266330112 (260088K bytes) avail memory = 252575744 (246656K bytes) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs If it does that, then: add to the src/lib/libdisk/Makefile: CFLAGS += -g in src/lib/libdisk: make obj make depend make clean make all install add to src/usr.sbin/sysinstall/Makefile CFLAGS += -static -g in src/usr.sbin/sysinstall: make obj make depend make clean make all install Now, try again and see if you don't get a more useful core file. I did all the steps above. The results are probably less helpful but I'm still game to more instructions. GDB was hitting its heuristic fence-post trying to load the core file so I ran the sysinstall in the obj directory since it wasn't stripped. This may be a bug in gdb that's hiding. Here is what I get running the non-stripped version. alpha# gdb -c sysinstall.core /usr/obj/usr/src/usr.sbin/sysinstall/sysinstall GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as alpha-undermydesk-freebsd... Core was generated by `sysinstall'. Program terminated with signal 11, Segmentation fault. #0 0x12008f764 in strtoul () (gdb) bt #0 0x12008f764 in strtoul () #1 0x1200aa000 in tcflow () #2 0x120084e40 in strdup () #3 0x1200aa000 in tcflow () warning: Hit heuristic-fence-post without finding warning: enclosing function for address 0x1201d6000 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. I did a quick search for tcflow but I think it's in some other library that got linked in there. -Michael _ http://fastmail.ca/ - Fast Secure Web Email for Canadians
Re: sysinstall alpha problems...
1st thing: Make sure you have removed the NO_GEOM option from your kernel config, sysinstall/libdisk only works with GEOM kernels. This was the problem. I think sysinstall should have a graceful way to detect this and return a complaint to the user rather than return a corefile. Now, more bugs... Maybe sysinstall has changed, but I can't seem to find any way to partition these drives. One was previously partitioned on an i386 box so I've at least been able to fool with it. 1) With try creating a filesystem C, for the size enter 1M. The error says The minimum filesystem size is 1MB) 2) If you hit A for auto defaults all it will create the following for me: da2a / 128MB UFS Y da2b swap 507MB SWAP da2d /var 256MB UFS+S Y da2e /tmp 256MB UFS+S Y da2f /usr 7535MB UFS+S Y Recreating them manually works if and only if the mount points are copied. That is to say, if I'm trying to make a copy from a live system, I can't create a da2a by specifying the mount point as /mnt/temproot in order to copy the files from it. I think this is more of an oversight than a bug since it chooses the device name based on the mount point. 3) once I've finally specified my filesystem. In this case it's: da2d /dr/dr02 8683MB UFS+S Y I hit W and it flashes some errors up on the screen and pops an error dialog box saying: ERROR: Unable to write data to disk da2! After that you can't touch the disk because it complains it was already written. The only way is of you exit sysinstall. I think that little flag in the software should only get set if it was written successfully. As for why it's not writing, I don't know. I tried finding MAKEDEV and running it on da2. crw-r- 1 root operator4, 2 Nov 1 17:54 /dev/da2 crw-r- 1 root operator4, 14 Nov 1 17:54 /dev/da2b crw-r- 1 root operator4, 15 Nov 1 17:54 /dev/da2c crw-r- 1 root operator4, 16 Nov 1 17:54 /dev/da2e crw-r- 1 root operator4, 17 Nov 1 17:54 /dev/da2f crw-r- 1 root operator4, 18 Nov 1 17:54 /dev/da2g So the devices exist. I think the 2 disks are set up properly but I'll have to watch it boot just to make 100% sure they didn't end up on the same ID. da1 at ahc0 bus 0 target 0 lun 0 da1: SEAGATE ST39103LW 0002 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da2 at ahc0 bus 0 target 1 lun 0 da2: SEAGATE ST39103LW 0002 Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) That's all I can come up with so far. My apologies if I'm not doing anything right... After all it's Friday and I should be off drinking beer. -Michael _ http://fastmail.ca/ - Fast Secure Web Email for Canadians
Re: disk quota overriding
On Wed, 17 Mar 1999, Jon Hamilton wrote: } touch big_file } chmod 777 big_file } chown root:wheel big_file } cat /dev/zero big_file } This joke used to work on HPUX 10.something which kept the } owner-may-chown semantics even in presence of quotas. It was not funny. } (I don't know whether HP has fixed that). Under HP-UX 9.x, the behavior you describe was the default, and it was changable by altering a kernel config parameter and relinking the kernel. The same tunable is available under 10.x, but I'm less certain what the default behavior is there. Whether quotas are enabled or not does not affect the behavior, only the kernel tunable parameter. We all know that there are oodles of security problems associated with file giveaways. As I recall, all the texts I have ever read on the subject say that unless there is a very good reason to allow giveaways, they should be disabled. -Michael To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
