Re: mount: /dev/da0p1: Invalid argument
On Fri, 8 Feb 2013 12:30:51 GMT, Anton Shterenlikht wrote: So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? Use the most universal file system which isn't even a file system: tar. First, create a tar archive (not a _file_!) to the USB media as if it was a tape. On the sparc machine: # tar cvf /dev/da0 your stuff You can add compression flags like z and j if you need. To list what you've got, use tar t accordingly. Then uncompress directly from the media on the non-sparc machine: # tar xvf /dev/da0 See man tar for other options you might want to add. Also note that in this case, no file system is involved, so you can't mount anything here. In the end I burned a CD with the files in question, but it's a bit of a waste, as I only need to move over several KB of data (wireless setup). That's true. Don't you have any floppies at hand? ;-) (Note: The tar approach also works on floppies, and even across OS borders, e. g. between Solaris and Linux.) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
On Fri, 8 Feb 2013 08:07:12 -0500 (EST), Chris Hill wrote: On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. While this may work for ordinary purposes, it can cause trouble due to limitations of file name length, possibly also characters in file names, and maximum file sizes. If those factors are not triggered, it seems to be okay. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
On Fri, Feb 08, 2013 at 12:01:41PM +, Anton Shterenlikht wrote: I need to transfer some files from sparc64 -current box onto amd64 9.1-RELEASE laptop. The amd64 laptop has no network connection yet, so I'm trying to achive this with a USB flash drive. The problem is that I always end up with # mount /dev/da0p1 /mnt/ mount: /dev/da0p1: Invalid argument # If I do newfs on the sparc64 box, then I can't mount it on the amd64 box, and vice versa. I tried just newfs /dev/da0, and using gpart, e.g.: # gpart show /dev/da0 = 34 4029373 da0 GPT (1.9G) 34 20481 freebsd-ufs (1.0M) 2082 4027325 - free - (1.9G) # and then newfs /dev/da0p1, or similar, but no luck. I tried sparc64 VTOC8 partition scheme too - no help. I can mount the device and use it as expected, i.e. copy files to/from it on either box, but the other box doesn't seem to understand the file system. I tried loading various modules in desperation, e.g. on the sparc64 side: # kldstat Id Refs AddressSize Name 19 0xc000 a80e58 kernel 21 0x101bca000 104000 geom_part_mbr.ko 31 0x101cce000 11 geom_label.ko 41 0x101dde000 108000 geom_part_gpt.ko # but still no use. Am I missing something simple? UFS on FreeBSD is not endian-agnostic. It uses the host byte order for multibyte values. As result, you can share UFS volumes only between hosts with the same endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. AFAIK, NetBSD has such support. pgpMA5jSqcvKS.pgp Description: PGP signature
Re: mount: /dev/da0p1: Invalid argument
From kostik...@gmail.com Fri Feb 8 12:25:21 2013 On Fri, Feb 08, 2013 at 12:01:41PM +, Anton Shterenlikht wrote: I need to transfer some files from sparc64 -current box onto amd64 9.1-RELEASE laptop. The amd64 laptop has no network connection yet, so I'm trying to achive this with a USB flash drive.=20 =20 The problem is that I always end up with =20 # mount /dev/da0p1 /mnt/ mount: /dev/da0p1: Invalid argument #=20 =20 If I do newfs on the sparc64 box, then I can't mount it on the amd64 box, and vice versa. =20 I tried just newfs /dev/da0, and using gpart, e.g.: =20 # gpart show /dev/da0 =3D 34 4029373 da0 GPT (1.9G) 34 20481 freebsd-ufs (1.0M) 2082 4027325 - free - (1.9G) =20 # =20 and then newfs /dev/da0p1, or similar, but no luck. =20 I tried sparc64 VTOC8 partition scheme too - no help. =20 I can mount the device and use it as expected, i.e. copy files to/from it on either box, but the other box doesn't seem to understand the file system. =20 I tried loading various modules in desperation, e.g. on the sparc64 side: =20 # kldstat=20 Id Refs AddressSize Name 19 0xc000 a80e58 kernel 21 0x101bca000 104000 geom_part_mbr.ko 31 0x101cce000 11 geom_label.ko 41 0x101dde000 108000 geom_part_gpt.ko #=20 =20 but still no use.=20 =20 Am I missing something simple? UFS on FreeBSD is not endian-agnostic. It uses the host byte order for multibyte values. As result, you can share UFS volumes only between hosts with the same endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. AFAIK, NetBSD has such support. Wow... I didn't realise that. I thought UFS (1 or 2) takes all care of endian-ness. Do you mean that even I had say a SCSI internal disk with UFS2, I couldn't move it between a little and a big endian freebsd boxes? So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? In the end I burned a CD with the files in question, but it's a bit of a waste, as I only need to move over several KB of data (wireless setup). Thanks Anton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
On Fri, Feb 08, 2013 at 12:30:51PM +, Anton Shterenlikht wrote: From kostik...@gmail.com Fri Feb 8 12:25:21 2013 On Fri, Feb 08, 2013 at 12:01:41PM +, Anton Shterenlikht wrote: I need to transfer some files from sparc64 -current box onto amd64 9.1-RELEASE laptop. The amd64 laptop has no network connection yet, so I'm trying to achive this with a USB flash drive.=20 =20 The problem is that I always end up with =20 # mount /dev/da0p1 /mnt/ mount: /dev/da0p1: Invalid argument #=20 =20 If I do newfs on the sparc64 box, then I can't mount it on the amd64 box, and vice versa. =20 I tried just newfs /dev/da0, and using gpart, e.g.: =20 # gpart show /dev/da0 =3D 34 4029373 da0 GPT (1.9G) 34 20481 freebsd-ufs (1.0M) 2082 4027325 - free - (1.9G) =20 # =20 and then newfs /dev/da0p1, or similar, but no luck. =20 I tried sparc64 VTOC8 partition scheme too - no help. =20 I can mount the device and use it as expected, i.e. copy files to/from it on either box, but the other box doesn't seem to understand the file system. =20 I tried loading various modules in desperation, e.g. on the sparc64 side: =20 # kldstat=20 Id Refs AddressSize Name 19 0xc000 a80e58 kernel 21 0x101bca000 104000 geom_part_mbr.ko 31 0x101cce000 11 geom_label.ko 41 0x101dde000 108000 geom_part_gpt.ko #=20 =20 but still no use.=20 =20 Am I missing something simple? UFS on FreeBSD is not endian-agnostic. It uses the host byte order for multibyte values. As result, you can share UFS volumes only between hosts with the same endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. AFAIK, NetBSD has such support. Wow... I didn't realise that. I thought UFS (1 or 2) takes all care of endian-ness. Do you mean that even I had say a SCSI internal disk with UFS2, I couldn't move it between a little and a big endian freebsd boxes? So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? FAT should work and ZFS is also endian-agnostic. I don't know how well these code paths of the latter are tested though and we seem to have grown bugs in this regard at least in the area of intra- ZFS-version compatibility (which due to lack of understanding of the ZFS internals I'm not able to fix) since the split from (Open) Solaris. Marius ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
Date: Fri, 8 Feb 2013 12:30:51 GMT From: Anton Shterenlikht me...@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument From kostik...@gmail.com Fri Feb 8 12:25:21 2013 On Fri, Feb 08, 2013 at 12:01:41PM +, Anton Shterenlikht wrote: I need to transfer some files from sparc64 -current box onto amd64 9.1-RELEASE laptop. The amd64 laptop has no network connection yet, so I'm trying to achive this with a USB flash drive.=20 =20 The problem is that I always end up with =20 # mount /dev/da0p1 /mnt/ mount: /dev/da0p1: Invalid argument #=20 =20 If I do newfs on the sparc64 box, then I can't mount it on the amd64 box, and vice versa. =20 I tried just newfs /dev/da0, and using gpart, e.g.: =20 # gpart show /dev/da0 =3D 34 4029373 da0 GPT (1.9G) 34 20481 freebsd-ufs (1.0M) 2082 4027325 - free - (1.9G) =20 # =20 and then newfs /dev/da0p1, or similar, but no luck. =20 I tried sparc64 VTOC8 partition scheme too - no help. =20 I can mount the device and use it as expected, i.e. copy files to/from it on either box, but the other box doesn't seem to understand the file system. =20 I tried loading various modules in desperation, e.g. on the sparc64 side: =20 # kldstat=20 Id Refs AddressSize Name 19 0xc000 a80e58 kernel 21 0x101bca000 104000 geom_part_mbr.ko 31 0x101cce000 11 geom_label.ko 41 0x101dde000 108000 geom_part_gpt.ko #=20 =20 but still no use.=20 =20 Am I missing something simple? UFS on FreeBSD is not endian-agnostic. It uses the host byte order for multibyte values. As result, you can share UFS volumes only between hosts with the same endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. AFAIK, NetBSD has such support. Wow... I didn't realise that. I thought UFS (1 or 2) takes all care of endian-ness. Do you mean that even I had say a SCSI internal disk with UFS2, I couldn't move it between a little and a big endian freebsd boxes? So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? you could use zfs. easier is to use the media as src/dest for tar/gtar/bsdtar/etc. tar is endian-agnostic, although there may be endian-ness issues with binary data in files inside the tarball. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. -- Chris Hill ch...@monochrome.org ** [ Busy Expunging / ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
From ch...@monochrome.org Fri Feb 8 13:27:48 2013 On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. But how do I create FAT32 partitions on FreeBSD? The gpart doesn't seem to support it. Anton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
From bon...@mail.r-bonomi.com Fri Feb 8 13:27:49 2013 From: Anton Shterenlikht me...@bristol.ac.uk Subject: Re: mount: /dev/da0p1: Invalid argument From kostik...@gmail.com Fri Feb 8 12:25:21 2013 On Fri, Feb 08, 2013 at 12:01:41PM +, Anton Shterenlikht wrote: I need to transfer some files from sparc64 -current box onto amd64 9.1-RELEASE laptop. The amd64 laptop has no network connection yet, so I'm trying to achive this with a USB flash drive.=20 =20 The problem is that I always end up with =20 # mount /dev/da0p1 /mnt/ mount: /dev/da0p1: Invalid argument #=20 =20 If I do newfs on the sparc64 box, then I can't mount it on the amd64 box, and vice versa. =20 I tried just newfs /dev/da0, and using gpart, e.g.: =20 # gpart show /dev/da0 =3D 34 4029373 da0 GPT (1.9G) 34 20481 freebsd-ufs (1.0M) 2082 4027325 - free - (1.9G) =20 # =20 and then newfs /dev/da0p1, or similar, but no luck. =20 I tried sparc64 VTOC8 partition scheme too - no help. =20 I can mount the device and use it as expected, i.e. copy files to/from it on either box, but the other box doesn't seem to understand the file system. =20 I tried loading various modules in desperation, e.g. on the sparc64 side: =20 # kldstat=20 Id Refs AddressSize Name 19 0xc000 a80e58 kernel 21 0x101bca000 104000 geom_part_mbr.ko 31 0x101cce000 11 geom_label.ko 41 0x101dde000 108000 geom_part_gpt.ko #=20 =20 but still no use.=20 =20 Am I missing something simple? UFS on FreeBSD is not endian-agnostic. It uses the host byte order for multibyte values. As result, you can share UFS volumes only between hosts with the same endianess, like i386/amd64/ia64 little endian or sparc64/mips big endian. AFAIK, NetBSD has such support. Wow... I didn't realise that. I thought UFS (1 or 2) takes all care of endian-ness. Do you mean that even I had say a SCSI internal disk with UFS2, I couldn't move it between a little and a big endian freebsd boxes? So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? you could use zfs. easier is to use the media as src/dest for tar/gtar/bsdtar/etc. tar is endian-agnostic, although there may be endian-ness issues with binary data in files inside the tarball. Yes, tar works, e.g. on sparc64 side: # tar -cf - /home/mexas/ftree.gv | dd of=/dev/da0 tar: Removing leading '/' from member names 20+0 records in 20+0 records out 10240 bytes transferred in 0.214031 secs (47844 bytes/sec) # Then on amd64 side: #dd if=/dev/da0 | tar -xf - I've got my file. The only problem is that the last command never stopped. I had to terminate it with CTRL/C. Is that the right syntax at all? Thanks Anton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
On 02/08/13 07:38, Anton Shterenlikht wrote: From ch...@monochrome.org Fri Feb 8 13:27:48 2013 On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. But how do I create FAT32 partitions on FreeBSD? The gpart doesn't seem to support it. Anton for a new fat32 fs I used: newfs_msdos -F 32 -L travelsize /dev/da0 (FreeBSD 9.1 amd64 over here, for what it's worth) -- Yours in Christ, Joseph A Nagy Jr Whoever loves instruction loves knowledge, But he who hates correction is stupid. -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://copyfree.org/licenses/owl/license.txt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
On 02/08/13 14:47, Joseph A. Nagy, Jr wrote: On 02/08/13 07:38, Anton Shterenlikht wrote: From ch...@monochrome.org Fri Feb 8 13:27:48 2013 On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. But how do I create FAT32 partitions on FreeBSD? The gpart doesn't seem to support it. Anton for a new fat32 fs I used: newfs_msdos -F 32 -L travelsize /dev/da0 (FreeBSD 9.1 amd64 over here, for what it's worth) Joseph is right in saying newfs_msdos -F 32 is how to format a FAT32 file system, but it occurs to me that Anton might be asking what type to specify to the gpart add command. Looking at http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs and http://en.wikipedia.org/wiki/Basic_data_partition I think you probably want to use the type code for a Windows Basic data partition, which would be gpart add -t !EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 other_gpart_args [depending on your shell you may have to escape that '!']. According to the second Wikipedia page According to Microsoft, the basic data partition is the equivalent to partition types 0x06, 0x07, and 0x0B (FAT16, NTFS, FAT32) in the traditional MBR partition table. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
From jnagyjr1...@gmail.com Fri Feb 8 14:47:22 2013 On 02/08/13 07:38, Anton Shterenlikht wrote: From ch...@monochrome.org Fri Feb 8 13:27:48 2013 On Fri, 8 Feb 2013, Anton Shterenlikht wrote: [ snip ] So what is the advice for transferring data via USB in such cases? Any other gpart partition I could use? I've always used FAT32 for thumb drives and the like. I don't know if the SPARC would be able to use it, but FAT32 seems like it's most likely to be usable by the largest number of different platforms. But how do I create FAT32 partitions on FreeBSD? The gpart doesn't seem to support it. Anton for a new fat32 fs I used: newfs_msdos -F 32 -L travelsize /dev/da0 (FreeBSD 9.1 amd64 over here, for what it's worth) got it, thanks. Seems it works on sparc64 too. Thanks Anton ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: mount: /dev/da0p1: Invalid argument
On Fri, 8 Feb 2013, Arthur Chance wrote: http://en.wikipedia.org/wiki/Basic_data_partition I think you probably want to use the type code for a Windows Basic data partition, which would be gpart add -t !EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 other_gpart_args [depending on your shell you may have to escape that '!']. According to the second Wikipedia page According to Microsoft, the basic data partition is the equivalent to partition types 0x06, 0x07, and 0x0B (FAT16, NTFS, FAT32) in the traditional MBR partition table. I just use type 12: # gpart add -t \!12 ... It would be kind of nice if gpart had some keywords for those types, though. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
