Re: NFS exports of ZFS snapshots broken
Oh, and thanks to everyone who put up with my lame ZFS snapshot questions. rick On Thu, Nov 23, 2023 at 8:13 AM Rick Macklem wrote: > > On Sat, Nov 18, 2023 at 8:10 PM Mike Karels wrote: > > > > On 18 Nov 2023, at 21:19, Rick Macklem wrote: > > > > > On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote: > > >> > > >> On 18 Nov 2023, at 17:23, Rick Macklem wrote: > > >> > > >>> On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: > > >>>> > > >>>> On 18 Nov 2023, at 15:58, Rick Macklem wrote: > > >>>> > > >>>>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem > > >>>>> wrote: > > >>>>>> > > >>>>>> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > > >>>>>>> > > >>>>>>> On 17 Nov 2023, at 22:14, Mike Karels wrote: > > >>>>>>> > > >>>>>>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > > >>>>>>>> > > >>>>>>>>> Most of the changes in stable/13 that are not in releng/13.2 > > >>>>>>>>> are the "make it work in a jail" stuff. Unfortunately, they are > > >>>>>>>>> a large # of changes (mostly trivial edits adding vnet macros), > > >>>>>>>>> but it also includes export check changes. > > >>>>>>>>> > > >>>>>>>>> I have attached a trivial patch that I think disables the export > > >>>>>>>>> checks for jails. If either of you can try it and see if it fixes > > >>>>>>>>> the problem, that would be great. > > >>>>>>>>> (Note that this is only for testing, although it probably does not > > >>>>>>>>> matter unless you are running nfsd(8) in vnet jails.) > > >>>>>>>> > > >>>>>>>> Yes, I can see snapshots with the patch. This system is just a > > >>>>>>>> test > > >>>>>>>> system that doesn't normally run ZFS or NFS, so no problem messing > > >>>>>>>> with permissions. It's a bhyve VM, so I just added a small disk > > >>>>>>>> and > > >>>>>>>> enabled ZFS for testing. > > >>>>>>> > > >>>>>>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > > >>>>>>> side. It must be doing something differently inside a snapshot than > > >>>>>>> outside, maybe with file handles or something like that. > > >>>>>> Yes. I've added freebsd-current@ (although Garrett is not on it, he > > >>>>>> is > > >>>>>> cc'd) and these guys specifically... > > >>>>>> > > >>>>>> So, here's what appears to be the problem... > > >>>>>> Commit 88175af (in main and stable/13, but not 13.2) added checks for > > >>>>>> nfsd(8) running in jails by filling in mnt_exjail with a reference > > >>>>>> to the cred > > >>>>>> used when the file system is exported. > > >>>>>> When mnt_exjail is found NULL, the current nfsd code assumes that > > >>>>>> there > > >>>>>> is no access allowed for the mount. > > >>>>>> > > >>>>>> My vague understanding is that when a ZFS snapshot is accessed, it is > > >>>>>> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > > >>>>>> mnt_exjail is NULL as a result. > > >>>>>> Since I do not know the ZFS code and don't even have an easy way to > > >>>>>> test this (thankfully Mike can test easily), I do not know what to > > >>>>>> do from > > >>>>>> here? > > >>>>>> > > >>>>>> Is there a "struct mount" constructed for this pseudo mount > > >>>>>> (or it actually appears to be the lookup of ".." that fails, so it > > >>>>>> might be the parent of the snapshot subdir?)? > > >>>>>> > > >>>>>> One thought is that
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 8:10 PM Mike Karels wrote: > > On 18 Nov 2023, at 21:19, Rick Macklem wrote: > > > On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote: > >> > >> On 18 Nov 2023, at 17:23, Rick Macklem wrote: > >> > >>> On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: > >>>> > >>>> On 18 Nov 2023, at 15:58, Rick Macklem wrote: > >>>> > >>>>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem > >>>>> wrote: > >>>>>> > >>>>>> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > >>>>>>> > >>>>>>> On 17 Nov 2023, at 22:14, Mike Karels wrote: > >>>>>>> > >>>>>>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > >>>>>>>> > >>>>>>>>> Most of the changes in stable/13 that are not in releng/13.2 > >>>>>>>>> are the "make it work in a jail" stuff. Unfortunately, they are > >>>>>>>>> a large # of changes (mostly trivial edits adding vnet macros), > >>>>>>>>> but it also includes export check changes. > >>>>>>>>> > >>>>>>>>> I have attached a trivial patch that I think disables the export > >>>>>>>>> checks for jails. If either of you can try it and see if it fixes > >>>>>>>>> the problem, that would be great. > >>>>>>>>> (Note that this is only for testing, although it probably does not > >>>>>>>>> matter unless you are running nfsd(8) in vnet jails.) > >>>>>>>> > >>>>>>>> Yes, I can see snapshots with the patch. This system is just a test > >>>>>>>> system that doesn't normally run ZFS or NFS, so no problem messing > >>>>>>>> with permissions. It's a bhyve VM, so I just added a small disk and > >>>>>>>> enabled ZFS for testing. > >>>>>>> > >>>>>>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > >>>>>>> side. It must be doing something differently inside a snapshot than > >>>>>>> outside, maybe with file handles or something like that. > >>>>>> Yes. I've added freebsd-current@ (although Garrett is not on it, he is > >>>>>> cc'd) and these guys specifically... > >>>>>> > >>>>>> So, here's what appears to be the problem... > >>>>>> Commit 88175af (in main and stable/13, but not 13.2) added checks for > >>>>>> nfsd(8) running in jails by filling in mnt_exjail with a reference to > >>>>>> the cred > >>>>>> used when the file system is exported. > >>>>>> When mnt_exjail is found NULL, the current nfsd code assumes that there > >>>>>> is no access allowed for the mount. > >>>>>> > >>>>>> My vague understanding is that when a ZFS snapshot is accessed, it is > >>>>>> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > >>>>>> mnt_exjail is NULL as a result. > >>>>>> Since I do not know the ZFS code and don't even have an easy way to > >>>>>> test this (thankfully Mike can test easily), I do not know what to do > >>>>>> from > >>>>>> here? > >>>>>> > >>>>>> Is there a "struct mount" constructed for this pseudo mount > >>>>>> (or it actually appears to be the lookup of ".." that fails, so it > >>>>>> might be the parent of the snapshot subdir?)? > >>>>>> > >>>>>> One thought is that I can check to see if the mount pointer is in the > >>>>>> mountlist (I don't think the snapshot's mount is in the mountlist) and > >>>>>> avoid the jail test for this case. This would assume that snapshots > >>>>>> are > >>>>>> always within the file system(s) exported via that jail (which includes > >>>>>> the case of prison0, of course), so that they do not need a separate > >>>>>> jail check. > >>>>>> > >>>>>> If this doesn't work,
Re: NFS exports of ZFS snapshots broken
On 18 Nov 2023, at 21:19, Rick Macklem wrote: > On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote: >> >> On 18 Nov 2023, at 17:23, Rick Macklem wrote: >> >>> On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: >>>> >>>> On 18 Nov 2023, at 15:58, Rick Macklem wrote: >>>> >>>>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem >>>>> wrote: >>>>>> >>>>>> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: >>>>>>> >>>>>>> On 17 Nov 2023, at 22:14, Mike Karels wrote: >>>>>>> >>>>>>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: >>>>>>>> >>>>>>>>> Most of the changes in stable/13 that are not in releng/13.2 >>>>>>>>> are the "make it work in a jail" stuff. Unfortunately, they are >>>>>>>>> a large # of changes (mostly trivial edits adding vnet macros), >>>>>>>>> but it also includes export check changes. >>>>>>>>> >>>>>>>>> I have attached a trivial patch that I think disables the export >>>>>>>>> checks for jails. If either of you can try it and see if it fixes >>>>>>>>> the problem, that would be great. >>>>>>>>> (Note that this is only for testing, although it probably does not >>>>>>>>> matter unless you are running nfsd(8) in vnet jails.) >>>>>>>> >>>>>>>> Yes, I can see snapshots with the patch. This system is just a test >>>>>>>> system that doesn't normally run ZFS or NFS, so no problem messing >>>>>>>> with permissions. It's a bhyve VM, so I just added a small disk and >>>>>>>> enabled ZFS for testing. >>>>>>> >>>>>>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS >>>>>>> side. It must be doing something differently inside a snapshot than >>>>>>> outside, maybe with file handles or something like that. >>>>>> Yes. I've added freebsd-current@ (although Garrett is not on it, he is >>>>>> cc'd) and these guys specifically... >>>>>> >>>>>> So, here's what appears to be the problem... >>>>>> Commit 88175af (in main and stable/13, but not 13.2) added checks for >>>>>> nfsd(8) running in jails by filling in mnt_exjail with a reference to >>>>>> the cred >>>>>> used when the file system is exported. >>>>>> When mnt_exjail is found NULL, the current nfsd code assumes that there >>>>>> is no access allowed for the mount. >>>>>> >>>>>> My vague understanding is that when a ZFS snapshot is accessed, it is >>>>>> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that >>>>>> mnt_exjail is NULL as a result. >>>>>> Since I do not know the ZFS code and don't even have an easy way to >>>>>> test this (thankfully Mike can test easily), I do not know what to do >>>>>> from >>>>>> here? >>>>>> >>>>>> Is there a "struct mount" constructed for this pseudo mount >>>>>> (or it actually appears to be the lookup of ".." that fails, so it >>>>>> might be the parent of the snapshot subdir?)? >>>>>> >>>>>> One thought is that I can check to see if the mount pointer is in the >>>>>> mountlist (I don't think the snapshot's mount is in the mountlist) and >>>>>> avoid the jail test for this case. This would assume that snapshots are >>>>>> always within the file system(s) exported via that jail (which includes >>>>>> the case of prison0, of course), so that they do not need a separate >>>>>> jail check. >>>>>> >>>>>> If this doesn't work, there will need to be some sort of messing about >>>>>> in ZFS to set mnt_exjail for these. >>>>> Ok, so now onto the hard part... >>>>> Thanks to Mike and others, I did create a snapshot under .zfs and I can >>>>> see the problem. It is that mnt_exjail == NULL. >>>>> Now, is there a way that this "struct mount" can be recognized as
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 4:43 PM Mike Karels wrote: > > On 18 Nov 2023, at 17:23, Rick Macklem wrote: > > > On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: > >> > >> On 18 Nov 2023, at 15:58, Rick Macklem wrote: > >> > >>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem > >>> wrote: > >>>> > >>>> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > >>>>> > >>>>> On 17 Nov 2023, at 22:14, Mike Karels wrote: > >>>>> > >>>>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > >>>>>> > >>>>>>> Most of the changes in stable/13 that are not in releng/13.2 > >>>>>>> are the "make it work in a jail" stuff. Unfortunately, they are > >>>>>>> a large # of changes (mostly trivial edits adding vnet macros), > >>>>>>> but it also includes export check changes. > >>>>>>> > >>>>>>> I have attached a trivial patch that I think disables the export > >>>>>>> checks for jails. If either of you can try it and see if it fixes > >>>>>>> the problem, that would be great. > >>>>>>> (Note that this is only for testing, although it probably does not > >>>>>>> matter unless you are running nfsd(8) in vnet jails.) > >>>>>> > >>>>>> Yes, I can see snapshots with the patch. This system is just a test > >>>>>> system that doesn't normally run ZFS or NFS, so no problem messing > >>>>>> with permissions. It's a bhyve VM, so I just added a small disk and > >>>>>> enabled ZFS for testing. > >>>>> > >>>>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > >>>>> side. It must be doing something differently inside a snapshot than > >>>>> outside, maybe with file handles or something like that. > >>>> Yes. I've added freebsd-current@ (although Garrett is not on it, he is > >>>> cc'd) and these guys specifically... > >>>> > >>>> So, here's what appears to be the problem... > >>>> Commit 88175af (in main and stable/13, but not 13.2) added checks for > >>>> nfsd(8) running in jails by filling in mnt_exjail with a reference to > >>>> the cred > >>>> used when the file system is exported. > >>>> When mnt_exjail is found NULL, the current nfsd code assumes that there > >>>> is no access allowed for the mount. > >>>> > >>>> My vague understanding is that when a ZFS snapshot is accessed, it is > >>>> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > >>>> mnt_exjail is NULL as a result. > >>>> Since I do not know the ZFS code and don't even have an easy way to > >>>> test this (thankfully Mike can test easily), I do not know what to do > >>>> from > >>>> here? > >>>> > >>>> Is there a "struct mount" constructed for this pseudo mount > >>>> (or it actually appears to be the lookup of ".." that fails, so it > >>>> might be the parent of the snapshot subdir?)? > >>>> > >>>> One thought is that I can check to see if the mount pointer is in the > >>>> mountlist (I don't think the snapshot's mount is in the mountlist) and > >>>> avoid the jail test for this case. This would assume that snapshots are > >>>> always within the file system(s) exported via that jail (which includes > >>>> the case of prison0, of course), so that they do not need a separate > >>>> jail check. > >>>> > >>>> If this doesn't work, there will need to be some sort of messing about > >>>> in ZFS to set mnt_exjail for these. > >>> Ok, so now onto the hard part... > >>> Thanks to Mike and others, I did create a snapshot under .zfs and I can > >>> see the problem. It is that mnt_exjail == NULL. > >>> Now, is there a way that this "struct mount" can be recognized as > >>> "special" > >>> for snapshots, so I can avoid the mnt_exjail == NULL test? > >>> (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not > >>> the case.) > >> > >>
Re: NFS exports of ZFS snapshots broken
On 18 Nov 2023, at 17:23, Rick Macklem wrote: > On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: >> >> On 18 Nov 2023, at 15:58, Rick Macklem wrote: >> >>> On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote: >>>> >>>> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: >>>>> >>>>> On 17 Nov 2023, at 22:14, Mike Karels wrote: >>>>> >>>>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: >>>>>> >>>>>>> Most of the changes in stable/13 that are not in releng/13.2 >>>>>>> are the "make it work in a jail" stuff. Unfortunately, they are >>>>>>> a large # of changes (mostly trivial edits adding vnet macros), >>>>>>> but it also includes export check changes. >>>>>>> >>>>>>> I have attached a trivial patch that I think disables the export >>>>>>> checks for jails. If either of you can try it and see if it fixes >>>>>>> the problem, that would be great. >>>>>>> (Note that this is only for testing, although it probably does not >>>>>>> matter unless you are running nfsd(8) in vnet jails.) >>>>>> >>>>>> Yes, I can see snapshots with the patch. This system is just a test >>>>>> system that doesn't normally run ZFS or NFS, so no problem messing >>>>>> with permissions. It's a bhyve VM, so I just added a small disk and >>>>>> enabled ZFS for testing. >>>>> >>>>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS >>>>> side. It must be doing something differently inside a snapshot than >>>>> outside, maybe with file handles or something like that. >>>> Yes. I've added freebsd-current@ (although Garrett is not on it, he is >>>> cc'd) and these guys specifically... >>>> >>>> So, here's what appears to be the problem... >>>> Commit 88175af (in main and stable/13, but not 13.2) added checks for >>>> nfsd(8) running in jails by filling in mnt_exjail with a reference to the >>>> cred >>>> used when the file system is exported. >>>> When mnt_exjail is found NULL, the current nfsd code assumes that there >>>> is no access allowed for the mount. >>>> >>>> My vague understanding is that when a ZFS snapshot is accessed, it is >>>> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that >>>> mnt_exjail is NULL as a result. >>>> Since I do not know the ZFS code and don't even have an easy way to >>>> test this (thankfully Mike can test easily), I do not know what to do from >>>> here? >>>> >>>> Is there a "struct mount" constructed for this pseudo mount >>>> (or it actually appears to be the lookup of ".." that fails, so it >>>> might be the parent of the snapshot subdir?)? >>>> >>>> One thought is that I can check to see if the mount pointer is in the >>>> mountlist (I don't think the snapshot's mount is in the mountlist) and >>>> avoid the jail test for this case. This would assume that snapshots are >>>> always within the file system(s) exported via that jail (which includes >>>> the case of prison0, of course), so that they do not need a separate >>>> jail check. >>>> >>>> If this doesn't work, there will need to be some sort of messing about >>>> in ZFS to set mnt_exjail for these. >>> Ok, so now onto the hard part... >>> Thanks to Mike and others, I did create a snapshot under .zfs and I can >>> see the problem. It is that mnt_exjail == NULL. >>> Now, is there a way that this "struct mount" can be recognized as "special" >>> for snapshots, so I can avoid the mnt_exjail == NULL test? >>> (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not >>> the case.) >> >> Dumb question, is the mount point (mp presumably) different between the >> snapshot and the main file system? > Not a dump question and the answer is rather interesting... > It is "sometimes" or "usually" according to my printf(). > It seems that when you first "cd where mnt_exjail == NULL.. Then when you look at directories within the > snapshot, you get the mp of the file system that .zfs exists in, which does > have mnt_exjai
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 2:27 PM Mike Karels wrote: > > On 18 Nov 2023, at 15:58, Rick Macklem wrote: > > > On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote: > >> > >> On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > >>> > >>> On 17 Nov 2023, at 22:14, Mike Karels wrote: > >>> > >>>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > >>>> > >>>>> Most of the changes in stable/13 that are not in releng/13.2 > >>>>> are the "make it work in a jail" stuff. Unfortunately, they are > >>>>> a large # of changes (mostly trivial edits adding vnet macros), > >>>>> but it also includes export check changes. > >>>>> > >>>>> I have attached a trivial patch that I think disables the export > >>>>> checks for jails. If either of you can try it and see if it fixes > >>>>> the problem, that would be great. > >>>>> (Note that this is only for testing, although it probably does not > >>>>> matter unless you are running nfsd(8) in vnet jails.) > >>>> > >>>> Yes, I can see snapshots with the patch. This system is just a test > >>>> system that doesn't normally run ZFS or NFS, so no problem messing > >>>> with permissions. It's a bhyve VM, so I just added a small disk and > >>>> enabled ZFS for testing. > >>> > >>> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > >>> side. It must be doing something differently inside a snapshot than > >>> outside, maybe with file handles or something like that. > >> Yes. I've added freebsd-current@ (although Garrett is not on it, he is > >> cc'd) and these guys specifically... > >> > >> So, here's what appears to be the problem... > >> Commit 88175af (in main and stable/13, but not 13.2) added checks for > >> nfsd(8) running in jails by filling in mnt_exjail with a reference to the > >> cred > >> used when the file system is exported. > >> When mnt_exjail is found NULL, the current nfsd code assumes that there > >> is no access allowed for the mount. > >> > >> My vague understanding is that when a ZFS snapshot is accessed, it is > >> "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > >> mnt_exjail is NULL as a result. > >> Since I do not know the ZFS code and don't even have an easy way to > >> test this (thankfully Mike can test easily), I do not know what to do from > >> here? > >> > >> Is there a "struct mount" constructed for this pseudo mount > >> (or it actually appears to be the lookup of ".." that fails, so it > >> might be the parent of the snapshot subdir?)? > >> > >> One thought is that I can check to see if the mount pointer is in the > >> mountlist (I don't think the snapshot's mount is in the mountlist) and > >> avoid the jail test for this case. This would assume that snapshots are > >> always within the file system(s) exported via that jail (which includes > >> the case of prison0, of course), so that they do not need a separate > >> jail check. > >> > >> If this doesn't work, there will need to be some sort of messing about > >> in ZFS to set mnt_exjail for these. > > Ok, so now onto the hard part... > > Thanks to Mike and others, I did create a snapshot under .zfs and I can > > see the problem. It is that mnt_exjail == NULL. > > Now, is there a way that this "struct mount" can be recognized as "special" > > for snapshots, so I can avoid the mnt_exjail == NULL test? > > (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not > > the case.) > > Dumb question, is the mount point (mp presumably) different between the > snapshot and the main file system? Not a dump question and the answer is rather interesting... It is "sometimes" or "usually" according to my printf(). It seems that when you first "cd . * * This is where we lie about our v_vfsp in order to * make .zfs/snapshot/ accessible over NFS * without requiring manual mounts of . */ ASSERT3P(VTOZ(*vpp)->z_zfsvfs, !=, zfsvfs); VTOZ(*vpp)->z_zfsvfs->z_parent = zfsvfs; /* Clear the root flag (set via VFS_ROOT) as well. */ (*vpp)->v_vflag &= ~VV_ROOT; which seems to set the mp to that of the parent, but it seems this does not happen for the initial lookup of the ? I'll note th
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 10:47 AM Ronald Klop wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca. > > > On 11/18/23 17:09, Rick Macklem wrote: > > On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > >> > >> On 17 Nov 2023, at 22:14, Mike Karels wrote: > >> > >>> On 17 Nov 2023, at 21:24, Rick Macklem wrote: > >>> > >>>> Most of the changes in stable/13 that are not in releng/13.2 > >>>> are the "make it work in a jail" stuff. Unfortunately, they are > >>>> a large # of changes (mostly trivial edits adding vnet macros), > >>>> but it also includes export check changes. > >>>> > >>>> I have attached a trivial patch that I think disables the export > >>>> checks for jails. If either of you can try it and see if it fixes > >>>> the problem, that would be great. > >>>> (Note that this is only for testing, although it probably does not > >>>> matter unless you are running nfsd(8) in vnet jails.) > >>> > >>> Yes, I can see snapshots with the patch. This system is just a test > >>> system that doesn't normally run ZFS or NFS, so no problem messing > >>> with permissions. It's a bhyve VM, so I just added a small disk and > >>> enabled ZFS for testing. > >> > >> btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > >> side. It must be doing something differently inside a snapshot than > >> outside, maybe with file handles or something like that. > > Yes. I've added freebsd-current@ (although Garrett is not on it, he is > > cc'd) and these guys specifically... > > > > So, here's what appears to be the problem... > > Commit 88175af (in main and stable/13, but not 13.2) added checks for > > nfsd(8) running in jails by filling in mnt_exjail with a reference to the > > cred > > used when the file system is exported. > > When mnt_exjail is found NULL, the current nfsd code assumes that there > > is no access allowed for the mount. > > > > My vague understanding is that when a ZFS snapshot is accessed, it is > > "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > > mnt_exjail is NULL as a result. > > Since I do not know the ZFS code and don't even have an easy way to > > test this (thankfully Mike can test easily), I do not know what to do from > > here? > > > > Is there a "struct mount" constructed for this pseudo mount > > (or it actually appears to be the lookup of ".." that fails, so it > > might be the parent of the snapshot subdir?)? > > > > One thought is that I can check to see if the mount pointer is in the > > mountlist (I don't think the snapshot's mount is in the mountlist) and > > avoid the jail test for this case. This would assume that snapshots are > > always within the file system(s) exported via that jail (which includes > > the case of prison0, of course), so that they do not need a separate > > jail check. > > > > If this doesn't work, there will need to be some sort of messing about > > in ZFS to set mnt_exjail for these. > > > > I will try and get a test setup going here, which leads me to.. > > how do I create a ZFS snapshot? (I do have a simple ZFS pool running > > on a test machine, but I've never done a snapshot.) > > # zfs list > ... > zroot/usr/local4.59G 27.5G 2.76G /usr/local > zroot/usr/ports1.03G 27.5G 952M /usr/ports > ... > > # zfs snapshot zroot/usr/local@myfirstsnapshot > -- to view them > # zfs list -t snapshot zroot/usr/local > -- and to remove it: > # zfs destroy zroot/usr/local@myfirstsnapshot > -- more info > # man zfs-snapshot > > If you get used to this you are going to love it. :-) Not likely. My test systems are old laptops and don't need fancy storage. However, I do have one very simple setup for testing. To give you a clue, it's called /example because the description I found to do it used "example" and I didn't even realize it would end up as the name of the mount. However, thanks to Mike and others, I do now have a snapshot on it. Now, as noted in my other post, comes the hard part. I hope I can identify that the "mount is special and refers to a snapshot" from the *mp,
Re: NFS exports of ZFS snapshots broken
On Sat, Nov 18, 2023 at 8:09 AM Rick Macklem wrote: > > On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > > > > On 17 Nov 2023, at 22:14, Mike Karels wrote: > > > > > On 17 Nov 2023, at 21:24, Rick Macklem wrote: > > > > > >> Most of the changes in stable/13 that are not in releng/13.2 > > >> are the "make it work in a jail" stuff. Unfortunately, they are > > >> a large # of changes (mostly trivial edits adding vnet macros), > > >> but it also includes export check changes. > > >> > > >> I have attached a trivial patch that I think disables the export > > >> checks for jails. If either of you can try it and see if it fixes > > >> the problem, that would be great. > > >> (Note that this is only for testing, although it probably does not > > >> matter unless you are running nfsd(8) in vnet jails.) > > > > > > Yes, I can see snapshots with the patch. This system is just a test > > > system that doesn't normally run ZFS or NFS, so no problem messing > > > with permissions. It's a bhyve VM, so I just added a small disk and > > > enabled ZFS for testing. > > > > btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > > side. It must be doing something differently inside a snapshot than > > outside, maybe with file handles or something like that. > Yes. I've added freebsd-current@ (although Garrett is not on it, he is > cc'd) and these guys specifically... > > So, here's what appears to be the problem... > Commit 88175af (in main and stable/13, but not 13.2) added checks for > nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred > used when the file system is exported. > When mnt_exjail is found NULL, the current nfsd code assumes that there > is no access allowed for the mount. > > My vague understanding is that when a ZFS snapshot is accessed, it is > "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that > mnt_exjail is NULL as a result. > Since I do not know the ZFS code and don't even have an easy way to > test this (thankfully Mike can test easily), I do not know what to do from > here? > > Is there a "struct mount" constructed for this pseudo mount > (or it actually appears to be the lookup of ".." that fails, so it > might be the parent of the snapshot subdir?)? > > One thought is that I can check to see if the mount pointer is in the > mountlist (I don't think the snapshot's mount is in the mountlist) and > avoid the jail test for this case. This would assume that snapshots are > always within the file system(s) exported via that jail (which includes > the case of prison0, of course), so that they do not need a separate > jail check. > > If this doesn't work, there will need to be some sort of messing about > in ZFS to set mnt_exjail for these. Ok, so now onto the hard part... Thanks to Mike and others, I did create a snapshot under .zfs and I can see the problem. It is that mnt_exjail == NULL. Now, is there a way that this "struct mount" can be recognized as "special" for snapshots, so I can avoid the mnt_exjail == NULL test? (I had hoped that "mp->mnt_list.tqe_prev" would be NULL, but that is not the case.) Do I need to search mountlist for it? rick ps: The hack patch attached should fix the problem, but can only be safely used if mountd/nfsd are not run in any jails. > > I will try and get a test setup going here, which leads me to.. > how do I create a ZFS snapshot? (I do have a simple ZFS pool running > on a test machine, but I've never done a snapshot.) > > Although this problem is not in 13.2, it will have shipped in 14.0. > > Any help with be appreciated, rick > > > > > Mike > > > > > >> rick > > >> > > >> On Fri, Nov 17, 2023 at 6:14 PM Mike Karels wrote: > > >>> > > >>> CAUTION: This email originated from outside of the University of > > >>> Guelph. Do not click links or open attachments unless you recognize the > > >>> sender and know the content is safe. If in doubt, forward suspicious > > >>> emails to ith...@uoguelph.ca. > > >>> > > >>> > > >>> Rick, have you been following this thread on freebsd-stable? I have > > >>> been able > > >>> to reproduce this using a 13-stable server from Oct 7 and a 15-current > > >>> system > > >>> that is up to date using NFSv3. I did not reproduce with a 13.2 > &g
Re: NFS exports of ZFS snapshots broken
On 11/18/23 17:09, Rick Macklem wrote: On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: On 17 Nov 2023, at 22:14, Mike Karels wrote: On 17 Nov 2023, at 21:24, Rick Macklem wrote: Most of the changes in stable/13 that are not in releng/13.2 are the "make it work in a jail" stuff. Unfortunately, they are a large # of changes (mostly trivial edits adding vnet macros), but it also includes export check changes. I have attached a trivial patch that I think disables the export checks for jails. If either of you can try it and see if it fixes the problem, that would be great. (Note that this is only for testing, although it probably does not matter unless you are running nfsd(8) in vnet jails.) Yes, I can see snapshots with the patch. This system is just a test system that doesn't normally run ZFS or NFS, so no problem messing with permissions. It's a bhyve VM, so I just added a small disk and enabled ZFS for testing. btw, you might try to get mm@ or maybe mav@ to help out from the ZFS side. It must be doing something differently inside a snapshot than outside, maybe with file handles or something like that. Yes. I've added freebsd-current@ (although Garrett is not on it, he is cc'd) and these guys specifically... So, here's what appears to be the problem... Commit 88175af (in main and stable/13, but not 13.2) added checks for nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred used when the file system is exported. When mnt_exjail is found NULL, the current nfsd code assumes that there is no access allowed for the mount. My vague understanding is that when a ZFS snapshot is accessed, it is "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that mnt_exjail is NULL as a result. Since I do not know the ZFS code and don't even have an easy way to test this (thankfully Mike can test easily), I do not know what to do from here? Is there a "struct mount" constructed for this pseudo mount (or it actually appears to be the lookup of ".." that fails, so it might be the parent of the snapshot subdir?)? One thought is that I can check to see if the mount pointer is in the mountlist (I don't think the snapshot's mount is in the mountlist) and avoid the jail test for this case. This would assume that snapshots are always within the file system(s) exported via that jail (which includes the case of prison0, of course), so that they do not need a separate jail check. If this doesn't work, there will need to be some sort of messing about in ZFS to set mnt_exjail for these. I will try and get a test setup going here, which leads me to.. how do I create a ZFS snapshot? (I do have a simple ZFS pool running on a test machine, but I've never done a snapshot.) # zfs list ... zroot/usr/local4.59G 27.5G 2.76G /usr/local zroot/usr/ports1.03G 27.5G 952M /usr/ports ... # zfs snapshot zroot/usr/local@myfirstsnapshot -- to view them # zfs list -t snapshot zroot/usr/local -- and to remove it: # zfs destroy zroot/usr/local@myfirstsnapshot -- more info # man zfs-snapshot If you get used to this you are going to love it. :-) Regards and happy hacking, Ronald. Although this problem is not in 13.2, it will have shipped in 14.0. Any help with be appreciated, rick Mike rick On Fri, Nov 17, 2023 at 6:14 PM Mike Karels wrote: CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca. Rick, have you been following this thread on freebsd-stable? I have been able to reproduce this using a 13-stable server from Oct 7 and a 15-current system that is up to date using NFSv3. I did not reproduce with a 13.2 server. The client was running 13.2. Any ideas? A full bisect seems fairly painful, but maybe you have an idea of points to try. Fortunately, these are all test systems that I can reboot at will. Mike Forwarded message: From: Garrett Wollman To: Mike Karels Cc: freebsd-sta...@freebsd.org Subject: Re: NFS exports of ZFS snapshots broken Date: Fri, 17 Nov 2023 17:35:04 -0500 < said: I have not run into this, so I tried it just now. I had no problem. The server is 13.2, fully patched, the client is up-to-date -current, and the mount is v4. On my 13.2 client and 13-stable server, I see: 25034 ls CALL open(0x237d32f9a000,0x120004) 25034 ls NAMI "/mnt/tools/.zfs/snapshot/weekly-2023-45" 25034 ls RET open 4 25034 ls CALL fcntl(0x4,F_ISUNIONSTACK,0x0) 25034 ls RET fcntl 0 25034 ls CALL getdirentries(0x4,0x237d32faa000,0x1000,0x237d32fa7028) 25034 ls RET getdirentries -1 errno 5 Input/output error 25034 ls CALL c
Re: NFS exports of ZFS snapshots broken
Rick Macklem wrote on Date: Sat, 18 Nov 2023 16:09:34 UTC: > . . . > I will try and get a test setup going here, which leads me to.. > how do I create a ZFS snapshot? (I do have a simple ZFS pool running > on a test machine, but I've never done a snapshot.) > . . . There is: "man zfs-snapshot" for "zfs snapshot" commands. I mention this in part because it references also using "zfs promote" to swap around the status of what is a snapshot vs. what is not. There is also the man page, accessible via: "man zfs-promote" . man zfs-snapshot also mentions destroying snapshots via "zfs destroy". The man pages have examples, such as: Example 1: Creating a ZFS Snapshot The following command creates a snapshot named yesterday. This snapshot is mounted on demand in the .zfs/snapshot directory at the root of the pool/home/bob file system. # zfs snapshot pool/home/bob@yesterday Example 3 involves all 3 operations (snapshot, promote, destroy) that I've referenced: Example 3: Promoting a ZFS Clone The following commands illustrate how to test out changes to a file system, and then replace the original file system with the changed one, using clones, clone promotion, and renaming: # zfs create pool/project/production populate /pool/project/production with data # zfs snapshot pool/project/production@today # zfs clone pool/project/production@today pool/project/beta make changes to /pool/project/beta and test them # zfs promote pool/project/beta # zfs rename pool/project/production pool/project/legacy # zfs rename pool/project/beta pool/project/production once the legacy version is no longer needed, it can be destroyed # zfs destroy pool/project/legacy The description of "zfs promote" is: DESCRIPTION The zfs promote command makes it possible to destroy the dataset that the clone was created from. The clone parent-child dependency relationship is reversed, so that the origin dataset becomes a clone of the specified dataset. The snapshot that was cloned, and any snapshots previous to this snapshot, are now owned by the promoted clone. The space they use moves from the origin dataset to the promoted clone, so enough space must be available to accommodate these snapshots. No new space is consumed by this operation, but the space accounting is adjusted. The promoted clone must not have any conflicting snapshot names of its own. The zfs rename subcommand can be used to rename any conflicting snapshots. === Mark Millard marklmi at yahoo.com
Re: NFS exports of ZFS snapshots broken
On Fri, Nov 17, 2023 at 8:19 PM Mike Karels wrote: > > On 17 Nov 2023, at 22:14, Mike Karels wrote: > > > On 17 Nov 2023, at 21:24, Rick Macklem wrote: > > > >> Most of the changes in stable/13 that are not in releng/13.2 > >> are the "make it work in a jail" stuff. Unfortunately, they are > >> a large # of changes (mostly trivial edits adding vnet macros), > >> but it also includes export check changes. > >> > >> I have attached a trivial patch that I think disables the export > >> checks for jails. If either of you can try it and see if it fixes > >> the problem, that would be great. > >> (Note that this is only for testing, although it probably does not > >> matter unless you are running nfsd(8) in vnet jails.) > > > > Yes, I can see snapshots with the patch. This system is just a test > > system that doesn't normally run ZFS or NFS, so no problem messing > > with permissions. It's a bhyve VM, so I just added a small disk and > > enabled ZFS for testing. > > btw, you might try to get mm@ or maybe mav@ to help out from the ZFS > side. It must be doing something differently inside a snapshot than > outside, maybe with file handles or something like that. Yes. I've added freebsd-current@ (although Garrett is not on it, he is cc'd) and these guys specifically... So, here's what appears to be the problem... Commit 88175af (in main and stable/13, but not 13.2) added checks for nfsd(8) running in jails by filling in mnt_exjail with a reference to the cred used when the file system is exported. When mnt_exjail is found NULL, the current nfsd code assumes that there is no access allowed for the mount. My vague understanding is that when a ZFS snapshot is accessed, it is "pseudo-mounted" by zfsctl_snapdir_lookup() and I am guessing that mnt_exjail is NULL as a result. Since I do not know the ZFS code and don't even have an easy way to test this (thankfully Mike can test easily), I do not know what to do from here? Is there a "struct mount" constructed for this pseudo mount (or it actually appears to be the lookup of ".." that fails, so it might be the parent of the snapshot subdir?)? One thought is that I can check to see if the mount pointer is in the mountlist (I don't think the snapshot's mount is in the mountlist) and avoid the jail test for this case. This would assume that snapshots are always within the file system(s) exported via that jail (which includes the case of prison0, of course), so that they do not need a separate jail check. If this doesn't work, there will need to be some sort of messing about in ZFS to set mnt_exjail for these. I will try and get a test setup going here, which leads me to.. how do I create a ZFS snapshot? (I do have a simple ZFS pool running on a test machine, but I've never done a snapshot.) Although this problem is not in 13.2, it will have shipped in 14.0. Any help with be appreciated, rick > > Mike > > > >> rick > >> > >> On Fri, Nov 17, 2023 at 6:14 PM Mike Karels wrote: > >>> > >>> CAUTION: This email originated from outside of the University of Guelph. > >>> Do not click links or open attachments unless you recognize the sender > >>> and know the content is safe. If in doubt, forward suspicious emails to > >>> ith...@uoguelph.ca. > >>> > >>> > >>> Rick, have you been following this thread on freebsd-stable? I have been > >>> able > >>> to reproduce this using a 13-stable server from Oct 7 and a 15-current > >>> system > >>> that is up to date using NFSv3. I did not reproduce with a 13.2 server. > >>> The > >>> client was running 13.2. Any ideas? A full bisect seems fairly painful, > >>> but > >>> maybe you have an idea of points to try. Fortunately, these are all test > >>> systems that I can reboot at will. > >>> > >>> Mike > >>> > >>> Forwarded message: > >>> > >>>> From: Garrett Wollman > >>>> To: Mike Karels > >>>> Cc: freebsd-sta...@freebsd.org > >>>> Subject: Re: NFS exports of ZFS snapshots broken > >>>> Date: Fri, 17 Nov 2023 17:35:04 -0500 > >>>> > >>>> < said: > >>>> > >>>>> I have not run into this, so I tried it just now. I had no problem. > >>>>> The server is 13.2, fully patched, the client is up-to-date -current, > >>>>> and the mount is v4. > >>>> > >>>&
New FreeBSD snapshots available: stable/14 (ALPHA4) (20230901 4c3f144478d4)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.
As with any development branch, the installation snapshots are not
intended for use on production systems. We do, however, encourage
testing on non-production systems as much as possible.
Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.
Checksums for the installation ISOs and the VM disk images follow at
the end of this email.
=== Installation ISOs ===
Installation images are available for:
o 14.0-ALPHA4 amd64 GENERIC
o 14.0-ALPHA4 i386 GENERIC
o 14.0-ALPHA4 powerpc GENERIC
o 14.0-ALPHA4 powerpc64 GENERIC64
o 14.0-ALPHA4 powerpc64le GENERIC64LE
o 14.0-ALPHA4 powerpcspe MPC85XXSPE
o 14.0-ALPHA4 armv7 GENERICSD
o 14.0-ALPHA4 aarch64 GENERIC
o 14.0-ALPHA4 aarch64 RPI
o 14.0-ALPHA4 aarch64 PINE64
o 14.0-ALPHA4 aarch64 PINE64-LTS
o 14.0-ALPHA4 aarch64 PINEBOOK
o 14.0-ALPHA4 aarch64 ROCK64
o 14.0-ALPHA4 aarch64 ROCKPRO64
o 14.0-ALPHA4 riscv64 GENERIC
o 14.0-ALPHA4 riscv64 GENERICSD
Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access. Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.
Snapshots may be downloaded from the corresponding architecture
directory from:
https://download.freebsd.org/snapshots/ISO-IMAGES/
Please be patient if your local mirror has not yet caught up with the
changes.
Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .
=== Virtual Machine Disk Images ===
VM disk images are available for the following architectures:
o 14.0-ALPHA4 amd64
o 14.0-ALPHA4 i386
o 14.0-ALPHA4 aarch64
o 14.0-ALPHA4 riscv64
o 14.0-ALPHA4 amd64 BASIC-CI
Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):
https://download.freebsd.org/snapshots/VM-IMAGES/
Images are available in the following disk image formats:
~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)
The partition layout for UFS images is:
~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)
Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images. This is provided by the emulators/qemu port.
To boot the VM image, run:
% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt
-bios /usr/local/share/qemu/edk2-aarch64-code.fd
-serial telnet::,server -nographic
-drive if=none,file=VMDISK,id=hd0
-device virtio-blk-device,drive=hd0
-device virtio-net-device,netdev=net0
-netdev user,id=net0
Be sure to replace "VMDISK" with the path to the virtual machine image.
BASIC-CI images can be found at:
https://download.freebsd.org/snapshots/CI-IMAGES/
=== Amazon EC2 AMI Images ===
Amazon EC2 AMI images available for FreeBSD/amd64.
These AMI IDs can be retrieved from the Systems Manager Parameter Store
in each region using the keys:
/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA4
/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA4
Amazon EC2 aarch64 AMI images are not available for this snapshot.
=== Vagrant Images ===
FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:
% vagrant init freebsd/FreeBSD-14.0-ALPHA4
% vagrant up
== ISO CHECKSUMS ==
o 14.0-ALPHA4 amd64 GENERIC:
SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-bootonly.iso)
=
be2a357b798b3a455da597bde4f89592eb73248cae7c61d613b523856c5f21b4e8607e9bb7f79eea74abab47cc0bb6007d6e207ef7fed558ad267c8162b6c8fe
SHA512
(FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-bootonly.iso.xz) =
750595e6f51553b468eb47b2ab0003a326903edc80b793da84fef827ec67532a9abdecc406d117762fa638b0bc8f3d9105f8bbda566d9410444c474281414180
SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-disc1.iso) =
5546879f2af755060905aa78e8f573e20ff3e318c42f56595a7db816f19a219f0cd1e8cbf72da2761757ae21278e507f8e17221a30c83b805e944d4ac5ee4aae
SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-disc1.iso.xz)
=
5168322946ed1a0a4ec69229eb51e798c037635aa849805d458a818d9930ece03a1d28b46c33987219074212c8ded60ba8ecbe3f5c06ed90718730b86351b7f1
SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-me
New FreeBSD snapshots available: stable/14 (ALPHA3) (20230825 2af9390e54ed)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.
As with any development branch, the installation snapshots are not
intended for use on production systems. We do, however, encourage
testing on non-production systems as much as possible.
Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.
Checksums for the installation ISOs and the VM disk images follow at
the end of this email.
=== Installation ISOs ===
Installation images are available for:
o 14.0-ALPHA3 amd64 GENERIC
o 14.0-ALPHA3 i386 GENERIC
o 14.0-ALPHA3 powerpc GENERIC
o 14.0-ALPHA3 powerpc64 GENERIC64
o 14.0-ALPHA3 powerpc64le GENERIC64LE
o 14.0-ALPHA3 powerpcspe MPC85XXSPE
o 14.0-ALPHA3 armv7 GENERICSD
o 14.0-ALPHA3 aarch64 GENERIC
o 14.0-ALPHA3 aarch64 RPI
o 14.0-ALPHA3 aarch64 PINE64
o 14.0-ALPHA3 aarch64 PINE64-LTS
o 14.0-ALPHA3 aarch64 PINEBOOK
o 14.0-ALPHA3 aarch64 ROCK64
o 14.0-ALPHA3 aarch64 ROCKPRO64
o 14.0-ALPHA3 riscv64 GENERIC
o 14.0-ALPHA3 riscv64 GENERICSD
Note, armv6 RPI-B images have been removed from the list of builds as
it is intended to be removed during the 14.0-RELEASE cycle.
Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access. Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.
Snapshots may be downloaded from the corresponding architecture
directory from:
https://download.freebsd.org/snapshots/ISO-IMAGES/
Please be patient if your local mirror has not yet caught up with the
changes.
Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .
=== Virtual Machine Disk Images ===
VM disk images are available for the following architectures:
o 14.0-ALPHA3 amd64
o 14.0-ALPHA3 i386
o 14.0-ALPHA3 aarch64
o 14.0-ALPHA3 riscv64
o 14.0-ALPHA3 amd64 BASIC-CI
Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):
https://download.freebsd.org/snapshots/VM-IMAGES/
Images are available in the following disk image formats:
~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)
The partition layout for UFS is:
~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)
Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images. This is provided by the emulators/qemu port.
To boot the VM image, run:
% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt
-bios /usr/local/share/qemu/edk2-aarch64-code.fd
-serial telnet::,server -nographic
-drive if=none,file=VMDISK,id=hd0
-device virtio-blk-device,drive=hd0
-device virtio-net-device,netdev=net0
-netdev user,id=net0
Be sure to replace "VMDISK" with the path to the virtual machine image.
BASIC-CI images can be found at:
https://download.freebsd.org/snapshots/VM-IMAGES/
=== Amazon EC2 AMI Images ===
FreeBSD amd64 and aarch64 EC2 AMIs are available for both UFS and ZFS.
These AMI IDs can be retrieved from the Systems Manager Parameter Store
in each region using the keys:
/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA3
/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA3
/aws/service/freebsd/arm64/base/ufs/14.0/ALPHA3
/aws/service/freebsd/arm64/base/zfs/14.0/ALPHA3
=== Vagrant Images ===
FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:
% vagrant init freebsd/FreeBSD-14.0-ALPHA3
% vagrant up
== ISO CHECKSUMS ==
o 14.0-ALPHA3 amd64 GENERIC:
SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-bootonly.iso)
=
7c7dd389aba9de05bc5a44c3268541fc336aa2bd4ede294a98d913ff1a79776a1bf974a828c81fcc7e44351685b89c5d6154563baec6e8c11859e546b3ee8a79
SHA512
(FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-bootonly.iso.xz) =
6a48dbddd901da8312a891a9f26309a443f9100dcbb88d9c78c20305917ba5da750de2d381e53118a704f88e83a29aec3d5365a87a37696ef01b98c6c08ab79b
SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-disc1.iso) =
f6903f80d8d6bf4498bc9df32d7d605e16061743fb7cd3935ed9aba337c18ac048c751443718bb395b8d20c178f31778f1057104ee225f0a4f7cbfa36563ddaa
SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-di
New FreeBSD snapshots available: main (ALPHA2) (20230819 77013f29d048)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.
As with any development branch, the installation snapshots are not
intended for use on production systems. We do, however, encourage
testing on non-production systems as much as possible.
Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.
Checksums for the installation ISOs and the VM disk images follow at
the end of this email.
=== Installation ISOs ===
Installation images are available for:
o 14.0-ALPHA2 amd64 GENERIC
o 14.0-ALPHA2 i386 GENERIC
o 14.0-ALPHA2 powerpc GENERIC
o 14.0-ALPHA2 powerpc64 GENERIC64
o 14.0-ALPHA2 powerpc64le GENERIC64LE
o 14.0-ALPHA2 powerpcspe MPC85XXSPE
o 14.0-ALPHA2 armv6 RPI-B
o 14.0-ALPHA2 armv7 GENERICSD
o 14.0-ALPHA2 aarch64 GENERIC
o 14.0-ALPHA2 aarch64 RPI
o 14.0-ALPHA2 aarch64 PINE64
o 14.0-ALPHA2 aarch64 PINE64-LTS
o 14.0-ALPHA2 aarch64 PINEBOOK
o 14.0-ALPHA2 aarch64 ROCK64
o 14.0-ALPHA2 aarch64 ROCKPRO64
o 14.0-ALPHA2 riscv64 GENERIC
o 14.0-ALPHA2 riscv64 GENERICSD
Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access. Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.
Snapshots may be downloaded from the corresponding architecture
directory from:
https://download.freebsd.org/snapshots/ISO-IMAGES/
Please be patient if your local mirror has not yet caught up with the
changes.
Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .
=== Virtual Machine Disk Images ===
VM disk images are available for the following architectures:
o 14.0-ALPHA2 amd64
o 14.0-ALPHA2 i386
o 14.0-ALPHA2 aarch64
o 14.0-ALPHA2 riscv64
o 14.0-ALPHA2 amd64 BASIC-CI
Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):
https://download.freebsd.org/snapshots/VM-IMAGES/
Images are available in the following disk image formats:
~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)
The partition layout is:
~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)
Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images. This is provided by the emulators/qemu port.
To boot the VM image, run:
% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt
-bios /usr/local/share/qemu/edk2-aarch64-code.fd
-serial telnet::,server -nographic
-drive if=none,file=VMDISK,id=hd0
-device virtio-blk-device,drive=hd0
-device virtio-net-device,netdev=net0
-netdev user,id=net0
Be sure to replace "VMDISK" with the path to the virtual machine image.
BASIC-CI images can be found at:
https://download.freebsd.org/snapshots/VM-IMAGES/
=== Amazon EC2 AMI Images ===
FreeBSD amd64 and aarch64 EC2 AMIs are available for both UFS and ZFS.
The AMI IDs can be retreived from the Systems Manager Parameter Store in
each region using the keys:
/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA2
/aws/service/freebsd/arm64/base/ufs/14.0/ALPHA2
/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA2
/aws/service/freebsd/arm64/base/zfs/14.0/ALPHA2
=== Vagrant Images ===
FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:
% vagrant init freebsd/FreeBSD-14.0-ALPHA2
% vagrant up
== ISO CHECKSUMS ==
o 14.0-ALPHA2 amd64 GENERIC:
SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-bootonly.iso)
=
02b4a7ba3a9520031607e6ebcbdf6cd142044aa1af40ad452c9d9793c5e70ebad94b13e679f5cb0aaa473e20f9da1f63b335b0cd25323aa03b14bd539b565ee1
SHA512
(FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-bootonly.iso.xz) =
966041afcb3df8cc35063592d67ad146453783941bff80fa019d42df6e624dca2a8763940f20a7cc3857bf708e6f76e1420ed18af4a1d287cec004bdd31893ee
SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-disc1.iso) =
76f8ff46e679d4920cfe67179a587abdfd323e83c3e3f79f39678f6a956b888cf4a2a1962f9a0549a1fb481912ef41fb666bd518dc1775e90488c31b841d6aca
SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-disc1.iso.xz)
=
c61970abd7f2b7c0a81d5bf702e3cc65129843e3624b1a93a1476ffe535adb8dbb13378b3b049d2e742e47383c3f6bb3b2b0678977ee11873c0b50414070ea1e
SHA512 (FreeBSD-1
Re: Lacking "arminess" (was Re: New FreeBSD snapshots available) (OFF TOPIC)
Ship it! Glen Sent from my phone. Please excuse my brevity and/or typos. > On Aug 13, 2023, at 2:39 PM, George Mitchell wrote: > > On 8/11/23 23:15, Glen Barber wrote: >> [...] >> It was discovered that due to human error (my own) the arm64 are, as >> Colin put it very politely, are "lacking 'arminess'". So, unfortunately >> the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64. >> [...] > Many years ago, one member of M.I.T.'s Tech Model Railroad Club had the > annoying habit of assembling his model airplanes in the clubroom. Soon, > the club enacted a rule banning all objects capable of sustained flight > from the club for a period o ninety-nine years and one day. Thereafter, > it became established procedure for the club to issue reprimands by > declaring certain people "capable of sustained flight." > > I now propose to express my displeasure with aspects of FreeBSD (which > almost never happens, honestly!) by declaring them to "lack arminess." > > My thanks to Glen Barber and Colin for creating this terminology. > -- George >
Re: New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)
On Fri, Aug 11, 2023 at 08:53:12PM +, Glen Barber wrote: [...] > FreeBSD/aarch64 UFS EC2 AMIs are available in the following regions: > [...] > > FreeBSD/aarch64 ZFS EC2 AMIs are available in the following regions: > [...] It was discovered that due to human error (my own) the arm64 are, as Colin put it very politely, are "lacking 'arminess'". So, unfortunately the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64. But you will receive a message stating it is the incorrect architecture, which is better than passively failing. Apologies for the inconvenience. Glen signature.asc Description: PGP signature
New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)
New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.
As with any development branch, the installation snapshots are not
intended for use on production systems. We do, however, encourage
testing on non-production systems as much as possible.
Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.
Checksums for the installation ISOs and the VM disk images follow at
the end of this email.
=== Installation ISOs ===
Installation images are available for:
o 14.0-ALPHA1 amd64 GENERIC
o 14.0-ALPHA1 i386 GENERIC
o 14.0-ALPHA1 powerpc GENERIC
o 14.0-ALPHA1 powerpc64 GENERIC64
o 14.0-ALPHA1 powerpc64le GENERIC64LE
o 14.0-ALPHA1 armv6 RPI-B
o 14.0-ALPHA1 armv7 GENERICSD
o 14.0-ALPHA1 aarch64 GENERIC
o 14.0-ALPHA1 aarch64 RPI
o 14.0-ALPHA1 aarch64 PINE64
o 14.0-ALPHA1 aarch64 PINE64-LTS
o 14.0-ALPHA1 aarch64 PINEBOOK
o 14.0-ALPHA1 aarch64 ROCK64
o 14.0-ALPHA1 aarch64 ROCKPRO64
o 14.0-ALPHA1 riscv64 GENERIC
o 14.0-ALPHA1 riscv64 GENERICSD
Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access. Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.
Snapshots may be downloaded from the corresponding architecture
directory from:
https://download.freebsd.org/snapshots/ISO-IMAGES/
Please be patient if your local mirror has not yet caught up with the
changes.
Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .
=== Virtual Machine Disk Images ===
VM disk images are available for the following architectures:
o 14.0-ALPHA1 amd64
o 14.0-ALPHA1 i386
o 14.0-ALPHA1 aarch64
o 14.0-ALPHA1 riscv64
o 14.0-ALPHA1 amd64 BASIC-CI
Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):
https://download.freebsd.org/snapshots/VM-IMAGES/
Images are available in the following disk image formats:
~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)
The partition layout for UFS is:
~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)
Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images. This is provided by the emulators/qemu port.
To boot the VM image, run:
% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt
-bios /usr/local/share/qemu/edk2-aarch64-code.fd
-serial telnet::,server -nographic
-drive if=none,file=VMDISK,id=hd0
-device virtio-blk-device,drive=hd0
-device virtio-net-device,netdev=net0
-netdev user,id=net0
Be sure to replace "VMDISK" with the path to the virtual machine image.
BASIC-CI images can be found at:
https://download.freebsd.org/snapshots/CI-IMAGES/
=== Amazon EC2 AMI Images ===
FreeBSD/amd64 UFS EC2 AMIs are available in the following regions:
ap-south-2 region: ami-0ee95230becf80778
ap-south-1 region: ami-03ad9777ff8bc0b6e
eu-south-1 region: ami-0fdfdb9f7c3a58c46
eu-south-2 region: ami-0ebed85d055e70b39
me-central-1 region: ami-02c67cb3a99d57d57
ca-central-1 region: ami-0d0bbdaefd0c0e181
eu-central-1 region: ami-0a80119c6edde9265
eu-central-2 region: ami-0a12f1c8e051dfae9
us-west-1 region: ami-0ea4f8fce960ef2c4
us-west-2 region: ami-09f3a6925f77e203e
af-south-1 region: ami-0ef9719a1228e32a5
eu-north-1 region: ami-02e6c8bc0ce909cbe
eu-west-3 region: ami-0aa3da21b9907069a
eu-west-2 region: ami-092c172d577027092
eu-west-1 region: ami-04cd2017e63b5ebda
ap-northeast-3 region: ami-077b46cc5d1c68523
ap-northeast-2 region: ami-00aafa3de31692805
me-south-1 region: ami-011ee7fb4001bf69f
ap-northeast-1 region: ami-08ff003b6ff73de93
sa-east-1 region: ami-052f0128aed100b4a
ap-east-1 region: ami-05bcf396a33918e60
ap-southeast-1 region: ami-0b56d17b45366f1bf
ap-southeast-2 region: ami-01b1c6fd1bb35074d
ap-southeast-3 region: ami-017073fdb4ae76333
us-east-1 region: ami-029e7b689f77cce2c
us-east-2 region: ami-0047bb65a2d73065f
FreeBSD/amd64 ZFS EC2 AMIs are available in the following regions:
ap-south-2 region: ami-0d3f563d617979348
ap-south-1 region: ami-03f77404c21fb5a25
eu-south-1 region: ami-0731187e3d49f6795
eu-south-2 region: ami-068b99a06abbe9a85
me-central-1 region: ami-0904554cdebb1ddab
ca-central-1 region: ami-0e96429bf976b35cb
eu-central-1 region: ami-0cb9214edc051fc88
eu-central-2 region: ami-0c4e6aad76680d64d
Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine
On Tue, 16 Nov 2021 at 23:22, Li-Wen Hsu wrote: > > You can use this command to list all the images built by re: > > gcloud compute images list --no-standard-images > --project=freebsd-org-cloud-dev Aside, it looks like we have many EOL images that are not marked as deprecated in the gcloud list (11.x and old 12.x images).
Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine
Thanks! That's just what I was looking for. On Tue, Nov 16, 2021 at 9:20 PM Li-Wen Hsu wrote: > > On Wed, Nov 17, 2021 at 11:56 AM Alan Somers wrote: > > > > Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and > > 13.0-RELEASE. Are there any images for current snapshots, and if so > > what are their names? > > -Alan > > You can use this command to list all the images built by re: > > gcloud compute images list --no-standard-images > --project=freebsd-org-cloud-dev > > gcloud is from net/google-cloud-sdk > > Li-Wen
Re: FreeBSD 14.0-CURRENT snapshots in Google Compute Engine
On Wed, Nov 17, 2021 at 11:56 AM Alan Somers wrote: > > Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and > 13.0-RELEASE. Are there any images for current snapshots, and if so > what are their names? > -Alan You can use this command to list all the images built by re: gcloud compute images list --no-standard-images --project=freebsd-org-cloud-dev gcloud is from net/google-cloud-sdk Li-Wen
FreeBSD 14.0-CURRENT snapshots in Google Compute Engine
Google Compute Engine has images for 11.4-RELEASE, 12.2-RELEASE, and 13.0-RELEASE. Are there any images for current snapshots, and if so what are their names? -Alan
Re: How to find out the revision for HEAD after build-snapshots-from-git?
On Fri, 25 Sep 2020 21:13:28 +0300 xto...@hotmail.com wrote: > Sergey V. Dyatko wrote: > > Hi, > > > > Possible I missed the answer to my question, sorry. But > > Today I installed FreeBSD from > > FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1 > > and now I want to rebuild kernel and so on BUT I don't know which SVN > > revision should I checkout. > > uname -a output: > > > > FreeBSD my.host.name 13.0-CURRENT FreeBSD 13.0-CURRENT #0 > > 3c514403bef-c253353(main): Thu Sep 24 06:45:17 UTC 2020 > > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > > > > r253353 looks too old, I suppose... > > There certainly should be easier way, but as a quick "fix", try > searching for commit hash: > > https://cgit-beta.freebsd.org/src/log/?qt=range&q=3c514403bef Looks amazing! but i'm not an Alien, I'm just a human... It is r366075, right ? Thanks! -- wbr, Sergey ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to find out the revision for HEAD after build-snapshots-from-git?
Sergey V. Dyatko wrote: Hi, Possible I missed the answer to my question, sorry. But Today I installed FreeBSD from FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1 and now I want to rebuild kernel and so on BUT I don't know which SVN revision should I checkout. uname -a output: FreeBSD my.host.name 13.0-CURRENT FreeBSD 13.0-CURRENT #0 3c514403bef-c253353(main): Thu Sep 24 06:45:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 r253353 looks too old, I suppose... There certainly should be easier way, but as a quick "fix", try searching for commit hash: https://cgit-beta.freebsd.org/src/log/?qt=range&q=3c514403bef ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
How to find out the revision for HEAD after build-snapshots-from-git?
Hi, Possible I missed the answer to my question, sorry. But Today I installed FreeBSD from FreeBSD-13.0-CURRENT-amd64-20200924-3c514403bef-disc1 and now I want to rebuild kernel and so on BUT I don't know which SVN revision should I checkout. uname -a output: FreeBSD my.host.name 13.0-CURRENT FreeBSD 13.0-CURRENT #0 3c514403bef-c253353(main): Thu Sep 24 06:45:17 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 r253353 looks too old, I suppose... -- wbr, Sergey ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, Sep 10, 2020 at 04:53:30PM +, Glen Barber wrote: > On Thu, Sep 10, 2020 at 06:43:08PM +0200, Emmanuel Vadot wrote: > > Which port commit and which board ? There haven't been a commit in the > > u-boot ports or rpi-firmware this a month now so I fails to understand > > without more info. > > > [...] > > But I think the build would have failed in this case if the fetch > succeeded, based on logs from other boards. > I have committed a fix to release/release.sh (r365725) that allows overriding the RELENGDIR variable if called from an external script, as well as committed fixes to ^/user/gjb/thermite-git/ (365752) which moves where RELENGDIR gets set for these boards. This week's builds should be fine. Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: main
clay@bsd13:~ $ uname -a FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT #0 1544934ffb2-c253004(main): Thu Sep 10 06:18:34 UTC 2020 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Works great, no problems with snapshot, thanks much Glen & everybody. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, Sep 10, 2020 at 06:43:08PM +0200, Emmanuel Vadot wrote: > On Thu, 10 Sep 2020 16:36:44 + > Glen Barber wrote: > > > On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote: > > > On Thu, 3 Sep 2020 16:00:51 + > > > Glen Barber wrote: > > > > > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > > > > > > > Hello, > > > > > > > > > > On Thu, 3 Sep 2020 15:02:45 + > > > > > Glen Barber wrote: > > > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > > Hash: SHA256 > > > > > > > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git > > > > > > sources. > > > > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > > > > investigated. > > > > > > > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do > > > > > you > > > > > have more info ? > > > > > > > > > > > > > The ports tree failed to mount within the chroot directory. I think > > > > I see why, and am testing a fix now. > > > > > > > > > > Looks like there was a problem this week too. > > > How can I help ? > > > > > > > Nothing really. I know what the problem is. The ports tree mounting > > issue had been fixed, but two things: 1) the u-boot port failed to > > fetch for at least one of the boards; 2) something got screwed up in the > > environment, due to path changes and how the git checkout structure is > > set up. > > > > The first is basically a timing issue with a ports commit and > > distribution of the distfiles. The second I am working on fixing now, > > which should be Relatively Easy(tm). > > > > Which port commit and which board ? There haven't been a commit in the > u-boot ports or rpi-firmware this a month now so I fails to understand > without more info. > The PINEBOOK fetch failed, but after closer inspection, it looks like a transient "Service not available" error. But I think the build would have failed in this case if the fetch succeeded, based on logs from other boards. Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, 10 Sep 2020 16:36:44 + Glen Barber wrote: > On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote: > > On Thu, 3 Sep 2020 16:00:51 + > > Glen Barber wrote: > > > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > > > > > Hello, > > > > > > > > On Thu, 3 Sep 2020 15:02:45 + > > > > Glen Barber wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA256 > > > > > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git > > > > > sources. > > > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > > > investigated. > > > > > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > > > have more info ? > > > > > > > > > > The ports tree failed to mount within the chroot directory. I think > > > I see why, and am testing a fix now. > > > > > > > Looks like there was a problem this week too. > > How can I help ? > > > > Nothing really. I know what the problem is. The ports tree mounting > issue had been fixed, but two things: 1) the u-boot port failed to > fetch for at least one of the boards; 2) something got screwed up in the > environment, due to path changes and how the git checkout structure is > set up. > > The first is basically a timing issue with a ports commit and > distribution of the distfiles. The second I am working on fixing now, > which should be Relatively Easy(tm). > > Glen > Which port commit and which board ? There haven't been a commit in the u-boot ports or rpi-firmware this a month now so I fails to understand without more info. -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote: > On Thu, 3 Sep 2020 16:00:51 + > Glen Barber wrote: > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > > > Hello, > > > > > > On Thu, 3 Sep 2020 15:02:45 + > > > Glen Barber wrote: > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA256 > > > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > > investigated. > > > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > > have more info ? > > > > > > > The ports tree failed to mount within the chroot directory. I think > > I see why, and am testing a fix now. > > > > Looks like there was a problem this week too. > How can I help ? > Nothing really. I know what the problem is. The ports tree mounting issue had been fixed, but two things: 1) the u-boot port failed to fetch for at least one of the boards; 2) something got screwed up in the environment, due to path changes and how the git checkout structure is set up. The first is basically a timing issue with a ports commit and distribution of the distfiles. The second I am working on fixing now, which should be Relatively Easy(tm). Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, 3 Sep 2020 16:00:51 + Glen Barber wrote: > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > > > Hello, > > > > On Thu, 3 Sep 2020 15:02:45 + > > Glen Barber wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > New FreeBSD development branch installation ISOs and virtual machine > > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > > > Also note: The armv6 and armv7 builds failed, and the cause is being > > > investigated. > > > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > > have more info ? > > > > The ports tree failed to mount within the chroot directory. I think > I see why, and am testing a fix now. > > Glen > Looks like there was a problem this week too. How can I help ? -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > Hello, > > On Thu, 3 Sep 2020 15:02:45 + > Glen Barber wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > New FreeBSD development branch installation ISOs and virtual machine > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > > Also note: The armv6 and armv7 builds failed, and the cause is being > > investigated. > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > have more info ? > The ports tree failed to mount within the chroot directory. I think I see why, and am testing a fix now. Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
Am 2020-09-03 17:02, schrieb Glen Barber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FreeBSD Project mirrors. === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 13.0-CURRENT amd64 o 13.0-CURRENT i386 o 13.0-CURRENT aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD Project mirrors): https://download.freebsd.org/ftp/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label) Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Hi, what about adding net/cloud-init to the images so that they can be used out-of-the-box on OpenStack? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238068 Best Regards Rainer ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
Hello, On Thu, 3 Sep 2020 15:02:45 + Glen Barber wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > New FreeBSD development branch installation ISOs and virtual machine > disk images have been uploaded to the FreeBSD Project mirrors. > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > Also note: The armv6 and armv7 builds failed, and the cause is being > investigated. There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you have more info ? Thanks, > As with any development branch, the installation snapshots are not > intended for use on production systems. We do, however, encourage > testing on non-production systems as much as possible. > > Please also consider installing the sysutils/panicmail port, which can > help in providing FreeBSD developers the necessary information regarding > system crashes. > > Checksums for the installation ISOs and the VM disk images follow at > the end of this email. > > === Installation ISOs === > > Installation images are available for: > > o 13.0-CURRENT amd64 GENERIC > o 13.0-CURRENT i386 GENERIC > o 13.0-CURRENT powerpc GENERIC > o 13.0-CURRENT powerpc64 GENERIC64 > o 13.0-CURRENT powerpcspe MPC85XXSPE > o 13.0-CURRENT aarch64 GENERIC > > Snapshots may be downloaded from the corresponding architecture > directory from: > > https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ > > Please be patient if your local mirror has not yet caught up with the > changes. > > Problems, bug reports, or regression reports should be reported through > the Bugzilla PR system or the appropriate mailing list such as -current@ > or -stable@ . > > === Virtual Machine Disk Images === > > VM disk images are available for the following architectures: > > o 13.0-CURRENT amd64 > o 13.0-CURRENT i386 > o 13.0-CURRENT aarch64 > > Disk images may be downloaded from the following URL (or any of the > FreeBSD Project mirrors): > > https://download.freebsd.org/ftp/snapshots/VM-IMAGES/ > > Images are available in the following disk image formats: > > ~ RAW > ~ QCOW2 (qemu) > ~ VMDK (qemu, VirtualBox, VMWare) > ~ VHD (qemu, xen) > > The partition layout is: > > ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) > ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) > ~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label) > > Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI > loader file is needed for qemu-system-aarch64 to be able to boot the > virtual machine images. See this page for more information: > > https://wiki.freebsd.org/arm64/QEMU > > To boot the VM image, run: > > % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ > -bios QEMU_EFI.fd -serial telnet::,server -nographic \ > -drive if=none,file=VMDISK,id=hd0 \ > -device virtio-blk-device,drive=hd0 \ > -device virtio-net-device,netdev=net0 \ > -netdev user,id=net0 > > Be sure to replace "VMDISK" with the path to the virtual machine image. > > === Amazon EC2 AMI Images === > > FreeBSD/amd64 EC2 AMIs are available in the following regions: > > af-south-1 region: ami-08c85df99f131c41e > eu-north-1 region: ami-092fee473b57ce293 > ap-south-1 region: ami-0f164c2f77d17c733 > eu-west-3 region: ami-0c76f6b53f6785c66 > eu-west-2 region: ami-029e99eecce2dccd7 > eu-south-1 region: ami-0631457525932e458 > eu-west-1 region: ami-052c5e4b4db76c3fb > ap-northeast-2 region: ami-03ca41a3cd4d23104 > me-south-1 region: ami-05cb623a383daf32f > ap-northeast-1 region: ami-06542baa9c54e8f57 > sa-east-1 region: ami-0b23146320070808d > ca-central-1 region: ami-0775c8ea1d4c51202 > ap-east-1 region: ami-0936d677fddabc97a > ap-southeast-1 region: ami-05e8f51cac90600cb > ap-southeast-2 region: ami-0f7682c07043d35b2 > eu-central-1 region: ami-0c18f8b05b7cf56ff > us-east-1 region: ami-0a95c17e40e205461 > us-east-2 region: ami-0df13af87e013a831 > us-west-1 region: ami-05a2ad30864e0a1f7 > us-west-2 region: ami-086dac6ecc576e960 > > FreeBSD/aarch64 EC2 AMIs are available in the following regions: > > af-south-1 region: ami-073a95521080cd18a > eu-north-1 region: ami-0c3fd8908dbb8d2d5 > ap-south-1 region: ami-05594776938632a06 > eu-west-3 region: ami-09f042df7c4285573 > eu-west-2 region: ami-05940e5f4a220a528 > eu-south-1 region: ami-02963fa721e775744 > eu-west-1 region: ami-0f70514fd820b09cd > ap-northeast-2 region: ami-03211c36231fe7bae > me-south-1 region: ami-0d9711b19def01556 > ap-northeast-1 region: ami-08c8af0923a2e
New FreeBSD snapshots available: main (20200903 c122cf32f2a)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FreeBSD Project mirrors. NOTE: These are the first snapshots built from the FreeBSD Git sources. Also note: The armv6 and armv7 builds failed, and the cause is being investigated. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 13.0-CURRENT amd64 GENERIC o 13.0-CURRENT i386 GENERIC o 13.0-CURRENT powerpc GENERIC o 13.0-CURRENT powerpc64 GENERIC64 o 13.0-CURRENT powerpcspe MPC85XXSPE o 13.0-CURRENT aarch64 GENERIC Snapshots may be downloaded from the corresponding architecture directory from: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Please be patient if your local mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 13.0-CURRENT amd64 o 13.0-CURRENT i386 o 13.0-CURRENT aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD Project mirrors): https://download.freebsd.org/ftp/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label) Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: af-south-1 region: ami-08c85df99f131c41e eu-north-1 region: ami-092fee473b57ce293 ap-south-1 region: ami-0f164c2f77d17c733 eu-west-3 region: ami-0c76f6b53f6785c66 eu-west-2 region: ami-029e99eecce2dccd7 eu-south-1 region: ami-0631457525932e458 eu-west-1 region: ami-052c5e4b4db76c3fb ap-northeast-2 region: ami-03ca41a3cd4d23104 me-south-1 region: ami-05cb623a383daf32f ap-northeast-1 region: ami-06542baa9c54e8f57 sa-east-1 region: ami-0b23146320070808d ca-central-1 region: ami-0775c8ea1d4c51202 ap-east-1 region: ami-0936d677fddabc97a ap-southeast-1 region: ami-05e8f51cac90600cb ap-southeast-2 region: ami-0f7682c07043d35b2 eu-central-1 region: ami-0c18f8b05b7cf56ff us-east-1 region: ami-0a95c17e40e205461 us-east-2 region: ami-0df13af87e013a831 us-west-1 region: ami-05a2ad30864e0a1f7 us-west-2 region: ami-086dac6ecc576e960 FreeBSD/aarch64 EC2 AMIs are available in the following regions: af-south-1 region: ami-073a95521080cd18a eu-north-1 region: ami-0c3fd8908dbb8d2d5 ap-south-1 region: ami-05594776938632a06 eu-west-3 region: ami-09f042df7c4285573 eu-west-2 region: ami-05940e5f4a220a528 eu-south-1 region: ami-02963fa721e775744 eu-west-1 region: ami-0f70514fd820b09cd ap-northeast-2 region: ami-03211c36231fe7bae me-south-1 region: ami-0d9711b19def01556 ap-northeast-1 region: ami-08c8af0923a2ec4f4 sa-east-1 region: ami-0405529811b49b9c2 ca-central-1 region: ami-0d2cdbbb55b331683 ap-east-1 region: ami-062a657fbd373cc97 ap-southeast-1 region: ami-0c4f30d508c70f510 ap-southeast-2 region: ami-00abe4775d151fb72 eu-central-1 region: ami-030dc94d2caf60616 us-east-1 region: ami-0035735483d37330c us-east-2 region: ami-01fc78890c9d8cf9d us-west-1 region: ami-014662c19db8b8287 us-west-2 region: ami-07f9261cecfeaf8f1 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-13.0-CURRENT % vagrant up == ISO CHECKSUMS == o 13.0-CURRENT amd64 GENERIC: SHA512 (FreeBSD-13.0-CURRENT-amd6
Re: ZFS: destroying snapshots without compromising boot environments
On 28/03/2020 15:19, Allan Jude wrote: > You can try to destroy the snapshot, if it is the basis of a clone, then > you will get an error, that you'd need to destroy the BE first, so you > might decide to keep that snapshot. As long as you don't use the -R flag > to zfs destroy dataset@snapshot, it will not destroy the clones. > > You can also use 'zfs promote' to make the clone into the parent, making > the original parent into the clone. This allows you to destroy that > original and the snapshot while keeping the clone. Perfect, thank you. I was nervous about destruction without warning. Below, are the differences (in measurement) between beadm and bectl to be expected? root@momh167-gjp4-8570p:~ # beadm list BE Active Mountpoint Space Created Waterfox - - 15.9G 2020-03-10 18:24 r357746f - - 1.3G 2020-03-20 06:19 r359249b NR / 74.7G 2020-03-28 01:19 root@momh167-gjp4-8570p:~ # beadm list -aDs BE/Dataset/Snapshot Active Mountpoint Space Created Waterfox copperbowl/ROOT/Waterfox - - 137.0M 2020-03-10 18:24 r359249b@2020-03-17-21:57:17 - - 59.2G 2020-03-17 21:57 copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 - - 67.0M 2020-03-20 06:19 r357746f copperbowl/ROOT/r357746f - - 1.2G 2020-03-20 06:19 Waterfox@2020-03-20-06:19:45 - - 59.2G 2020-03-20 06:19 r359249b copperbowl/ROOT/r359249b@2020-03-17-21:57:17 - - 15.7G 2020-03-17 21:57 copperbowl/ROOT/r359249b NR / 59.0G 2020-03-28 01:19 root@momh167-gjp4-8570p:~ # bectl list BE Active Mountpoint Space Created Waterfox - - 204M 2020-03-10 18:24 r357746f - - 1.21G 2020-03-20 06:19 r359249b NR / 74.7G 2020-03-28 01:19 root@momh167-gjp4-8570p:~ # bectl list -aDs BE/Dataset/Snapshot Active Mountpoint Space Created Waterfox copperbowl/ROOT/Waterfox - - 204M 2020-03-10 18:24 Waterfox@2020-03-20-06:19:45 - - 67.0M 2020-03-20 06:19 r357746f copperbowl/ROOT/r357746f - - 1.21G 2020-03-20 06:19 r359249b copperbowl/ROOT/r359249b NR / 74.7G 2020-03-28 01:19 r359249b@2020-03-17-21:57:17 - - 15.7G 2020-03-17 21:57 root@momh167-gjp4-8570p:~ # zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 67.0M - 59.2G - copperbowl/ROOT/r359249b@2020-03-17-21:57:17 15.7G - 59.2G - copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G - copperbowl/poudriere/jails/head@clean 328K - 1.89G - root@momh167-gjp4-8570p:~ # zfs destroy copperbowl/ROOT/r359249b@2020-03-17-21:57:17 cannot destroy 'copperbowl/ROOT/r359249b@2020-03-17-21:57:17': snapshot has dependent clones use '-R' to destroy the following datasets: copperbowl/ROOT/r357746f copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 copperbowl/ROOT/Waterfox root@momh167-gjp4-8570p:~ # date ; uname -v Sat Mar 28 15:30:57 GMT 2020 FreeBSD 13.0-CURRENT #1 r359249: Tue Mar 24 00:12:27 GMT 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@momh167-gjp4-8570p:~ # ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ZFS: destroying snapshots without compromising boot environments
On 2020-03-28 03:24, Graham Perrin wrote: > I imagine that some of the 2019 snapshots below are redundant. > > Can I safely destroy any of them? > > $ zfs list -t snapshot > NAME USED AVAIL > REFER MOUNTPOINT > copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 67.0M - 59.2G - > copperbowl/ROOT/r359249b@2019-08-18-04:04:53 5.82G - 40.9G - > copperbowl/ROOT/r359249b@2019-08-18-11:28:31 4.32G - 40.7G - > copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 9.43G - 43.4G - > copperbowl/ROOT/r359249b@2019-09-19-20:03:26 5.13G - 43.3G - > copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 7.67G - 44.6G - > copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 7.66G - 55.2G - > copperbowl/ROOT/r359249b@2020-01-11-14:15:47 7.41G - 56.2G - > copperbowl/ROOT/r359249b@2020-03-17-21:57:17 12.0G - 59.2G - > copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G - > copperbowl/poudriere/jails/head@clean 328K - 1.89G - > $ beadm list > BE Active Mountpoint Space Created > Waterfox - - 12.2G 2020-03-10 18:24 > r357746f - - 1.3G 2020-03-20 06:19 > r359249b NR / 148.9G 2020-03-28 01:19 > $ beadm list -aDs > BE/Dataset/Snapshot Active Mountpoint > Space Created > > Waterfox > copperbowl/ROOT/Waterfox - - 137.0M > 2020-03-10 18:24 > r359249b@2020-03-17-21:57:17 - - 59.2G > 2020-03-17 21:57 > copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 - - 67.0M > 2020-03-20 06:19 > > r357746f > copperbowl/ROOT/r357746f - - 1.2G > 2020-03-20 06:19 > Waterfox@2020-03-20-06:19:45 - - 59.2G > 2020-03-20 06:19 > > r359249b > copperbowl/ROOT/r359249b@2019-08-18-04:04:53 - - 5.8G > 2019-08-18 04:04 > copperbowl/ROOT/r359249b@2019-08-18-11:28:31 - - 4.3G > 2019-08-18 11:28 > copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - - 9.4G > 2019-09-13 18:45 > copperbowl/ROOT/r359249b@2019-09-19-20:03:26 - - 5.1G > 2019-09-19 20:03 > copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - - 7.7G > 2019-09-24 20:45 > copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - - 7.7G > 2020-01-09 17:05 > copperbowl/ROOT/r359249b@2020-01-11-14:15:47 - - 7.4G > 2020-01-11 14:15 > copperbowl/ROOT/r359249b@2020-03-17-21:57:17 - - 12.0G > 2020-03-17 21:57 > copperbowl/ROOT/r359249b NR / 59.0G > 2020-03-28 01:19 > $ > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" You can try to destroy the snapshot, if it is the basis of a clone, then you will get an error, that you'd need to destroy the BE first, so you might decide to keep that snapshot. As long as you don't use the -R flag to zfs destroy dataset@snapshot, it will not destroy the clones. You can also use 'zfs promote' to make the clone into the parent, making the original parent into the clone. This allows you to destroy that original and the snapshot while keeping the clone. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZFS: destroying snapshots without compromising boot environments
On Sat, Mar 28, 2020 at 10:30 AM Graham Perrin wrote: > > I imagine that some of the 2019 snapshots below are redundant. > > Can I safely destroy any of them? > > $ zfs list -t snapshot > NAME USED AVAIL > REFER MOUNTPOINT > copperbowl/ROOT/Waterfox@2020-03-20-06:19:4567.0M - 59.2G - > copperbowl/ROOT/r359249b@2019-08-18-04:04:535.82G - 40.9G - > copperbowl/ROOT/r359249b@2019-08-18-11:28:314.32G - 40.7G - > copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 9.43G - 43.4G - > copperbowl/ROOT/r359249b@2019-09-19-20:03:265.13G - 43.3G - > copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 7.67G - 44.6G - > copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 7.66G - 55.2G - > copperbowl/ROOT/r359249b@2020-01-11-14:15:477.41G - 56.2G - > copperbowl/ROOT/r359249b@2020-03-17-21:57:1712.0G - 59.2G - > copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G - > copperbowl/poudriere/jails/head@clean328K - 1.89G - > $ beadm list > BE Active Mountpoint Space Created > Waterfox - - 12.2G 2020-03-10 18:24 > r357746f - -1.3G 2020-03-20 06:19 > r359249b NR / 148.9G 2020-03-28 01:19 > $ beadm list -aDs > BE/Dataset/Snapshot Active Mountpoint > Space Created > > Waterfox >copperbowl/ROOT/Waterfox - - 137.0M > 2020-03-10 18:24 > r359249b@2020-03-17-21:57:17 - - 59.2G > 2020-03-17 21:57 >copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 - - 67.0M > 2020-03-20 06:19 > > r357746f >copperbowl/ROOT/r357746f - -1.2G > 2020-03-20 06:19 > Waterfox@2020-03-20-06:19:45 - - 59.2G > 2020-03-20 06:19 > > r359249b >copperbowl/ROOT/r359249b@2019-08-18-04:04:53 - -5.8G > 2019-08-18 04:04 >copperbowl/ROOT/r359249b@2019-08-18-11:28:31 - -4.3G > 2019-08-18 11:28 >copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - -9.4G > 2019-09-13 18:45 >copperbowl/ROOT/r359249b@2019-09-19-20:03:26 - -5.1G > 2019-09-19 20:03 >copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - -7.7G > 2019-09-24 20:45 >copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - -7.7G > 2020-01-09 17:05 >copperbowl/ROOT/r359249b@2020-01-11-14:15:47 - -7.4G > 2020-01-11 14:15 >copperbowl/ROOT/r359249b@2020-03-17-21:57:17 - - 12.0G > 2020-03-17 21:57 >copperbowl/ROOT/r359249b NR / 59.0G > 2020-03-28 01:19 > $ beadm destroy ? ;) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ZFS: destroying snapshots without compromising boot environments
I imagine that some of the 2019 snapshots below are redundant. Can I safely destroy any of them? $ zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 67.0M - 59.2G - copperbowl/ROOT/r359249b@2019-08-18-04:04:53 5.82G - 40.9G - copperbowl/ROOT/r359249b@2019-08-18-11:28:31 4.32G - 40.7G - copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 9.43G - 43.4G - copperbowl/ROOT/r359249b@2019-09-19-20:03:26 5.13G - 43.3G - copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 7.67G - 44.6G - copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 7.66G - 55.2G - copperbowl/ROOT/r359249b@2020-01-11-14:15:47 7.41G - 56.2G - copperbowl/ROOT/r359249b@2020-03-17-21:57:17 12.0G - 59.2G - copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers 8K - 1.24G - copperbowl/poudriere/jails/head@clean 328K - 1.89G - $ beadm list BE Active Mountpoint Space Created Waterfox - - 12.2G 2020-03-10 18:24 r357746f - - 1.3G 2020-03-20 06:19 r359249b NR / 148.9G 2020-03-28 01:19 $ beadm list -aDs BE/Dataset/Snapshot Active Mountpoint Space Created Waterfox copperbowl/ROOT/Waterfox - - 137.0M 2020-03-10 18:24 r359249b@2020-03-17-21:57:17 - - 59.2G 2020-03-17 21:57 copperbowl/ROOT/Waterfox@2020-03-20-06:19:45 - - 67.0M 2020-03-20 06:19 r357746f copperbowl/ROOT/r357746f - - 1.2G 2020-03-20 06:19 Waterfox@2020-03-20-06:19:45 - - 59.2G 2020-03-20 06:19 r359249b copperbowl/ROOT/r359249b@2019-08-18-04:04:53 - - 5.8G 2019-08-18 04:04 copperbowl/ROOT/r359249b@2019-08-18-11:28:31 - - 4.3G 2019-08-18 11:28 copperbowl/ROOT/r359249b@2019-09-13-18:45:27-0 - - 9.4G 2019-09-13 18:45 copperbowl/ROOT/r359249b@2019-09-19-20:03:26 - - 5.1G 2019-09-19 20:03 copperbowl/ROOT/r359249b@2019-09-24-20:45:59-0 - - 7.7G 2019-09-24 20:45 copperbowl/ROOT/r359249b@2020-01-09-17:05:57-0 - - 7.7G 2020-01-09 17:05 copperbowl/ROOT/r359249b@2020-01-11-14:15:47 - - 7.4G 2020-01-11 14:15 copperbowl/ROOT/r359249b@2020-03-17-21:57:17 - - 12.0G 2020-03-17 21:57 copperbowl/ROOT/r359249b NR / 59.0G 2020-03-28 01:19 $ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: head (20160701 r302303)
On Sat, Jul 02, 2016 at 09:26:14AM +0300, Ivan Klymenko wrote:
> On Sat, 2 Jul 2016 06:19:58 +
> Glen Barber wrote:
> ivan@nonamehost:/ % ftp
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/11.0-ALPHA6 Trying
> 77.88.40.106:21 ... Connected to ftp.geo.freebsd.org.
> 220 This is ftp0.ydx.freebsd.org - hosted at Yandex.
> 331 Please specify the password.
> 230-
> 230-This is ftp0.ydx.FreeBSD.org, graciously hosted by Yandex.
> 230-
> 230-FreeBSD files can be found in the /pub/FreeBSD directory.
> 230-
> 230 Login successful.
> Remote system type is UNIX.
> Using binary mode to transfer files.
> 200 Switching to Binary mode.
> 250 Directory successfully changed.
> 250-ISO images of FreeBSD releases may be found in the
> releases/ISO-IMAGES 250-directory. For independent files and tarballs,
> see individual 250-releases/${machine}/${machine_arch} directories.
> For example, 250-releases/amd64/amd64 and releases/powerpc/powerpc64.
> 250 Directory successfully changed.
> 250 Directory successfully changed.
> 250 Directory successfully changed.
> local: 11.0-ALPHA6 remote: 11.0-ALPHA6
> ftp: Can't access `11.0-ALPHA6': Permission denied
> 221 Goodbye.
These are snapshots, not official releases. Again:
Please be patient if your local FTP mirror has not yet caught
up with the changes.
Glen
signature.asc
Description: PGP signature
Re: New FreeBSD snapshots available: head (20160701 r302303)
On Sat, 2 Jul 2016 06:19:58 +
Glen Barber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> New FreeBSD development branch installation ISOs and virtual machine
> disk images have been uploaded to the FTP mirrors.
>
> As with any development branch, the installation snapshots are not
> intended for use on production systems. We do, however, encourage
> testing on non-production systems as much as possible.
>
> Please also consider installing the sysutils/panicmail port, which can
> help in providing FreeBSD developers the necessary information
> regarding system crashes.
>
> Checksums for the installation ISOs and the VM disk images follow at
> the end of this email.
>
ivan@nonamehost:/ % ftp
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA6 Trying
77.88.40.106:21 ... Connected to ftp.geo.freebsd.org.
220 This is ftp0.ydx.freebsd.org - hosted at Yandex.
331 Please specify the password.
230-
230-This is ftp0.ydx.FreeBSD.org, graciously hosted by Yandex.
230-
230-FreeBSD files can be found in the /pub/FreeBSD directory.
230-
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
200 Switching to Binary mode.
250 Directory successfully changed.
250-ISO images of FreeBSD releases may be found in the
releases/ISO-IMAGES 250-directory. For independent files and tarballs,
see individual 250-releases/${machine}/${machine_arch} directories.
For example, 250-releases/amd64/amd64 and releases/powerpc/powerpc64.
250 Directory successfully changed.
250 Directory successfully changed.
250 Directory successfully changed.
local: 11.0-ALPHA6 remote: 11.0-ALPHA6
ftp: Can't access `11.0-ALPHA6': Permission denied
221 Goodbye.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: head (20160624 r302164)
On Sat, Jun 25, 2016 at 02:13:24AM +, Glen Barber wrote: > New FreeBSD development branch installation ISOs and virtual machine > disk images have been uploaded to the FTP mirrors. > There have been a few reports of "missing" files on the FTP mirrors. This happened last week with the i386 MANIFEST file for base.txz, etc., and FreeBSD-11.0-ALPHA5-arm-armv6-BANANAPI-20160624-r302164.img.xz was missing this week (in addition to other files). I'm looking into the root cause, but if you notice something missing that should exist, please email me privately. (This is not an re@ issue, this is an admins@ issue, and I'm still trying to figure out what is going wrong.) Thanks, and apologies for anything I've missed. Glen signature.asc Description: PGP signature
New FreeBSD snapshots available: head (20160624 r302164)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA5 amd64 GENERIC o 11.0-ALPHA5 i386 GENERIC o 11.0-ALPHA5 armv6 BANANAPI o 11.0-ALPHA5 armv6 BEAGLEBONE o 11.0-ALPHA5 armv6 CUBIEBOARD o 11.0-ALPHA5 armv6 CUBIEBOARD2 o 11.0-ALPHA5 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA5 armv6 GUMSTIX o 11.0-ALPHA5 armv6 RPI-B o 11.0-ALPHA5 armv6 RPI2 o 11.0-ALPHA5 armv6 PANDABOARD o 11.0-ALPHA5 armv6 WANDBOARD o 11.0-ALPHA5 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA5 amd64 o 11.0-ALPHA5 i386 o 11.0-ALPHA5 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-0969a464 us-west-1 region: ami-8ba6e2eb us-west-2 region: ami-d419deb4 sa-east-1 region: ami-1ceb7e70 eu-west-1 region: ami-b93ea6ca eu-central-1 region: ami-1241a97d ap-northeast-1 region: ami-7ba1571a ap-northeast-2 region: ami-d8559eb6 ap-southeast-1 region: ami-a1c113c2 ap-southeast-2 region: ami-ecf3db8f === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA5 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA5 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-bootonly.iso) = f03a6b92be685afff6fe9788c90bde0957638cc094850929aa9ee532d86f38af4561ef80eaeee5fd2d823bc5bea872ea6711b3c81dc6e284ab4f81cad16892ca SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-bootonly.iso.xz) = 23e7a9c078ed1653454843f383c7695e7d81e7e12f92b8cb06c52c07d76b998e6f0d419ccdd5d8c19aab0d094d1b58a596f11664eb9c9dc96ea1c90b8613cb26 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-disc1.iso) = 940c18ba1f3d589bf6d0e66058bea0310388110bf64dc3df97d5f6402bc149137b05c41e02c3bf6bb188a7b285967324217265820e0d0a0ad83522c450ab0679 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-disc1.iso.xz) = 881e68e8399a1a26c6907d4e3bf8945c59660b6e74c27d432745bffbe0ac1b0aad2f728d4574f71b09f9b1728cd053107d24a0a2b5ae3d15c2b2e9aa760739ec SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-dvd1.iso) = 4dbc2bee256aa005d4620f998468890464e1517467cbd16509c6821b18283aaad29c173c1f3b3639f109cb8ba55de5bbe26c6d6a8823af4abe368b4339b875d5 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-dvd1.iso.xz) = 4601ccb01269c5cf55c81a050543e7f82e18527863d6b7fd24f374c31bab2c93f29f419c2ed336df64bd1f82e8b352780c14c7a49ea347fa0d600b7bd7224027 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-memstick.img) = e3657eaa8c7c6d32353c917fe3ccdbd1c6948d0ae947f4a3f1b247d8e3494346e4e5ede9c9c994110d377222485aba876b24d18555c1789578eae242203d03b7 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-memstick.img.xz) = 924b197c33b85cc9033f4b6808df5f211974a1a01719f5c6d4fee9db9751a3deed24d7117e4e2ef52413a46477a36021bdba8c2f9e66db0612f6cb9d943249a3 SHA512 (FreeBSD-11.0-ALPHA5-amd64-20160624-r302164-mini-memstick.img) = ce803ffc13ce9ce986adb36dbc22ca437a0c364e5a05689fc0d3ffbaffcb4e2e37434707051aa70732309246c02c77377576a94a8064dfbfd3137914b89466cf
Re: New FreeBSD snapshots available: head (20160617 r301975)
On Sun, Jun 19, 2016 at 10:48:02AM +0300, Ivan Klymenko wrote: > On Sat, 18 Jun 2016 23:07:22 + > Glen Barber wrote: > > > On Sat, Jun 18, 2016 at 02:02:50PM +, Glen Barber wrote: > > > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote: > > > > === Installation ISOs === > > > > > > > > Installation images are available for: > > > > > > > > o 11.0-ALPHA4 amd64 GENERIC > > > > o 11.0-ALPHA4 i386 GENERIC > > > > o 11.0-ALPHA4 powerpc GENERIC > > > > o 11.0-ALPHA4 powerpc64 GENERIC64 > > > > o 11.0-ALPHA4 sparc64 GENERIC > > > > o 11.0-ALPHA4 armv6 BANANAPI > > > > o 11.0-ALPHA4 armv6 BEAGLEBONE > > > > o 11.0-ALPHA4 armv6 CUBIEBOARD > > > > o 11.0-ALPHA4 armv6 CUBIEBOARD2 > > > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD > > > > o 11.0-ALPHA4 armv6 GUMSTIX > > > > o 11.0-ALPHA4 armv6 RPI-B > > > > o 11.0-ALPHA4 armv6 RPI2 > > > > o 11.0-ALPHA4 armv6 PANDABOARD > > > > o 11.0-ALPHA4 armv6 WANDBOARD > > > > o 11.0-ALPHA4 aarch64 GENERIC > > > > > > > > Hello. > > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ > > > > not have manifest file. > > > > > > Huh. Yep, this is a problem. > > > > > > Thank you for the report. I'll investigate what happened here. > > > > > > > This doesn't make sense. The MANIFEST exists on the build machine, > > and should have been copied as result of the distribution to the > > mirrors. > > > > I don't understand how it did not make it to the mirrors. > > > > So I know, how did you discover this? > > > > I *do* see the MANIFEST for amd64, so something very bizarre happened > > here. > > > > Glen > > > > It breaks my poudriere. > poudriere jail -c -v 11.0-ALPHA4 -a i386 -j 11_ALPHA4_i386 -m > url=ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ This is even stranger than originally thought. The MANIFEST file *does* exist now, but I did not manually put it there. I don't think anyone else did either. So, I have no idea what happened, but thank you for this report. One more thing to double-check before sending these emails. Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: head (20160617 r301975)
On Sat, 18 Jun 2016 23:07:22 + Glen Barber wrote: > On Sat, Jun 18, 2016 at 02:02:50PM +, Glen Barber wrote: > > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote: > > > === Installation ISOs === > > > > > > Installation images are available for: > > > > > > o 11.0-ALPHA4 amd64 GENERIC > > > o 11.0-ALPHA4 i386 GENERIC > > > o 11.0-ALPHA4 powerpc GENERIC > > > o 11.0-ALPHA4 powerpc64 GENERIC64 > > > o 11.0-ALPHA4 sparc64 GENERIC > > > o 11.0-ALPHA4 armv6 BANANAPI > > > o 11.0-ALPHA4 armv6 BEAGLEBONE > > > o 11.0-ALPHA4 armv6 CUBIEBOARD > > > o 11.0-ALPHA4 armv6 CUBIEBOARD2 > > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD > > > o 11.0-ALPHA4 armv6 GUMSTIX > > > o 11.0-ALPHA4 armv6 RPI-B > > > o 11.0-ALPHA4 armv6 RPI2 > > > o 11.0-ALPHA4 armv6 PANDABOARD > > > o 11.0-ALPHA4 armv6 WANDBOARD > > > o 11.0-ALPHA4 aarch64 GENERIC > > > > > > Hello. > > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ > > > not have manifest file. > > > > Huh. Yep, this is a problem. > > > > Thank you for the report. I'll investigate what happened here. > > > > This doesn't make sense. The MANIFEST exists on the build machine, > and should have been copied as result of the distribution to the > mirrors. > > I don't understand how it did not make it to the mirrors. > > So I know, how did you discover this? > > I *do* see the MANIFEST for amd64, so something very bizarre happened > here. > > Glen > It breaks my poudriere. poudriere jail -c -v 11.0-ALPHA4 -a i386 -j 11_ALPHA4_i386 -m url=ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: head (20160617 r301975)
On Sat, Jun 18, 2016 at 02:02:50PM +, Glen Barber wrote: > On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote: > > === Installation ISOs === > > > > Installation images are available for: > > > > o 11.0-ALPHA4 amd64 GENERIC > > o 11.0-ALPHA4 i386 GENERIC > > o 11.0-ALPHA4 powerpc GENERIC > > o 11.0-ALPHA4 powerpc64 GENERIC64 > > o 11.0-ALPHA4 sparc64 GENERIC > > o 11.0-ALPHA4 armv6 BANANAPI > > o 11.0-ALPHA4 armv6 BEAGLEBONE > > o 11.0-ALPHA4 armv6 CUBIEBOARD > > o 11.0-ALPHA4 armv6 CUBIEBOARD2 > > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD > > o 11.0-ALPHA4 armv6 GUMSTIX > > o 11.0-ALPHA4 armv6 RPI-B > > o 11.0-ALPHA4 armv6 RPI2 > > o 11.0-ALPHA4 armv6 PANDABOARD > > o 11.0-ALPHA4 armv6 WANDBOARD > > o 11.0-ALPHA4 aarch64 GENERIC > > > > Hello. > > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ not have > > manifest file. > > > > Huh. Yep, this is a problem. > > Thank you for the report. I'll investigate what happened here. > This doesn't make sense. The MANIFEST exists on the build machine, and should have been copied as result of the distribution to the mirrors. I don't understand how it did not make it to the mirrors. So I know, how did you discover this? I *do* see the MANIFEST for amd64, so something very bizarre happened here. Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: head (20160617 r301975)
On Sat, Jun 18, 2016 at 10:12:07AM +0300, fidaj wrote: > === Installation ISOs === > > Installation images are available for: > > o 11.0-ALPHA4 amd64 GENERIC > o 11.0-ALPHA4 i386 GENERIC > o 11.0-ALPHA4 powerpc GENERIC > o 11.0-ALPHA4 powerpc64 GENERIC64 > o 11.0-ALPHA4 sparc64 GENERIC > o 11.0-ALPHA4 armv6 BANANAPI > o 11.0-ALPHA4 armv6 BEAGLEBONE > o 11.0-ALPHA4 armv6 CUBIEBOARD > o 11.0-ALPHA4 armv6 CUBIEBOARD2 > o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD > o 11.0-ALPHA4 armv6 GUMSTIX > o 11.0-ALPHA4 armv6 RPI-B > o 11.0-ALPHA4 armv6 RPI2 > o 11.0-ALPHA4 armv6 PANDABOARD > o 11.0-ALPHA4 armv6 WANDBOARD > o 11.0-ALPHA4 aarch64 GENERIC > > Hello. > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ not have > manifest file. > Huh. Yep, this is a problem. Thank you for the report. I'll investigate what happened here. Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: head (20160617 r301975)
Please add the MANIFEST file to ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: head (20160617 r301975)
--- Оригінальне повідомлення --- Від кого: "Glen Barber" Дата: 18 червня 2016, 08:58:23 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA4 amd64 GENERIC o 11.0-ALPHA4 i386 GENERIC o 11.0-ALPHA4 powerpc GENERIC o 11.0-ALPHA4 powerpc64 GENERIC64 o 11.0-ALPHA4 sparc64 GENERIC o 11.0-ALPHA4 armv6 BANANAPI o 11.0-ALPHA4 armv6 BEAGLEBONE o 11.0-ALPHA4 armv6 CUBIEBOARD o 11.0-ALPHA4 armv6 CUBIEBOARD2 o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA4 armv6 GUMSTIX o 11.0-ALPHA4 armv6 RPI-B o 11.0-ALPHA4 armv6 RPI2 o 11.0-ALPHA4 armv6 PANDABOARD o 11.0-ALPHA4 armv6 WANDBOARD o 11.0-ALPHA4 aarch64 GENERIC Hello. ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/11.0-ALPHA4/ not have manifest file. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
New FreeBSD snapshots available: head (20160617 r301975)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA4 amd64 GENERIC o 11.0-ALPHA4 i386 GENERIC o 11.0-ALPHA4 powerpc GENERIC o 11.0-ALPHA4 powerpc64 GENERIC64 o 11.0-ALPHA4 sparc64 GENERIC o 11.0-ALPHA4 armv6 BANANAPI o 11.0-ALPHA4 armv6 BEAGLEBONE o 11.0-ALPHA4 armv6 CUBIEBOARD o 11.0-ALPHA4 armv6 CUBIEBOARD2 o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA4 armv6 GUMSTIX o 11.0-ALPHA4 armv6 RPI-B o 11.0-ALPHA4 armv6 RPI2 o 11.0-ALPHA4 armv6 PANDABOARD o 11.0-ALPHA4 armv6 WANDBOARD o 11.0-ALPHA4 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA4 amd64 o 11.0-ALPHA4 i386 o 11.0-ALPHA4 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-955395f8 us-west-1 region: ami-0cce8b6c us-west-2 region: ami-5e599c3e sa-east-1 region: ami-2277fd4e eu-west-1 region: ami-e87de39b eu-central-1 region: ami-d254bdbd ap-northeast-1 region: ami-44f80d25 ap-northeast-2 region: ami-a62fe4c8 ap-southeast-1 region: ami-f433e097 ap-southeast-2 region: ami-83b099e0 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA4 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA4 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-bootonly.iso) = cb0c889c9f9394a60cddc03858738f2fb1c0acf45b69d0fbc11ee4963559d9de2e44bfea013fdaa21d11d05cb430d9efdc42279735bc789e3cdb29ffa15c8d28 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-bootonly.iso.xz) = 64966d24a6ac9330d6c9be6b46f4dade6c2261fae76f274bd9fee800bd91ed7ba5310a986148d4c3368f88beb645fb1222f4a5b9a90713f80af71ef68627bc40 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-disc1.iso) = 077dc64a1707ff7cae9d82a79cf5f3ac12ad1a4fe950326d4562ba9dfb18deebd44a255a1dcba78607533789070dce0a536d0c141ac48a5e83792941748aa17b SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-disc1.iso.xz) = 62fae035091360af8238c31e65bb01d3c33b2a2cfd90fa877f09af59c448947608114bc1d4c1dd719d07097d08d9b3f8c561df33e1ae06a00ea89097cce4a705 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-dvd1.iso) = ef5304abba7598621d7f59d3831016a5a47edce69bfda824ba70864cd57e8d8d4019841f7a19ce8b676722651f52529fbd4367f261b0cbfd515ba253f1fffbe6 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-dvd1.iso.xz) = 15571b230d11c4d896964085220df234400fb5e093ffb0a0ec34667bb9ab5146eafc04c444609ebe94cce0c058bfe68f4c5f893c18c34d5d32733dbb77e3109f SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-memstick.img) = 426f31cc6672de4f3cd1457da5432388e33672d97df775a621e9925ba5ebbc68dd425c2aff6810664a6bec93944e509fe24b83a26dd5e43d79a6bc507694 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-memstick.img.xz) = 7f801f2748ffc0dd6f662923d947f57e268bb67faf512ca8aeeb0e31fa864f0207cb74bcbe3b68e764b74c08620ae5878b41a5d93387f0975b2485e50bae6246 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-mini-memstick.img
New FreeBSD snapshots available: head (20160528 r301230)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA2 amd64 GENERIC o 11.0-ALPHA2 powerpc GENERIC o 11.0-ALPHA2 powerpc64 GENERIC64 o 11.0-ALPHA2 sparc64 GENERIC o 11.0-ALPHA2 armv6 BANANAPI o 11.0-ALPHA2 armv6 BEAGLEBONE o 11.0-ALPHA2 armv6 CUBIEBOARD o 11.0-ALPHA2 armv6 CUBIEBOARD2 o 11.0-ALPHA2 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA2 armv6 GUMSTIX o 11.0-ALPHA2 armv6 RPI-B o 11.0-ALPHA2 armv6 RPI2 o 11.0-ALPHA2 armv6 PANDABOARD o 11.0-ALPHA2 armv6 WANDBOARD o 11.0-ALPHA2 aarch64 GENERIC Note: The i386 build failed due to an issue generating the doc.txz distribution, which is still undergoing investigation. Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA2 amd64 o 11.0-ALPHA2 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. The file can be found here, for now, until various patches are available upstream: http://people.FreeBSD.org/~gjb/QEMU_EFI.fd The checksums for this file are: SHA256 (QEMU_EFI.fd) = a35335a418781fc0963c80ab12d548b6972d2c0b955f45664a4b780f4e5f48a2 MD5 (QEMU_EFI.fd) = ec03d51a3c4374a515cf32ab0c2721cf To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \\ -bios QEMU_EFI.fd -serial telnet::,server -nographic \\ -drive if=none,file=VMDISK,id=hd0 \\ -device virtio-blk-device,drive=hd0 \\ -device virtio-net-device,netdev=net0 \\ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA2 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA2 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-bootonly.iso) = b6ecbad09f01e1044343229ee93552c7c6adfc1c0cbe07d1a876a679544c626775be05534ec619ef5383b5419acc13110df7f47301522b6f0393e62626e0d3cb SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-bootonly.iso.xz) = 3a5d9a57a38363d9c4def1df07ae13e814be72af77a1932e39c97ea11ffb28ac92c6290a50099ab8380cc6265f45214c307042a9f5c0727f87150a2b74479eb9 SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-disc1.iso) = 105c02b3736a2b7453a16a72b75be528362be5ebe0c5e1bb0a28f36814f298cb683e5de83d6813e249bbb27b820f55e1c93bb5b5f86cf07006efd07cdc80379c SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-disc1.iso.xz) = 8ded96a1fd3ff4d9456918db469d114df01f94222751ca5028a58b08b851bc365887e761d10b8b9f66234e832f1657223d1e09b00533210cf520aa5582c5fd5d SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-dvd1.iso) = fb4af5a3fe0dc84c5768ae21e71bd21275a3bdd827acde2a36d2a610ae08113f24d60f6dc27a14ff2acac0b54a165385bbe75bedc2601a161df20a7e4630aeba SHA512 (FreeBSD-11.0-ALPHA2-amd64-20160528-r301230-d
New FreeBSD snapshots available: head (20160528 r300895)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA1 amd64 GENERIC o 11.0-ALPHA1 i386 GENERIC o 11.0-ALPHA1 powerpc GENERIC o 11.0-ALPHA1 powerpc64 GENERIC64 o 11.0-ALPHA1 sparc64 GENERIC o 11.0-ALPHA1 armv6 BANANAPI o 11.0-ALPHA1 armv6 BEAGLEBONE o 11.0-ALPHA1 armv6 CUBIEBOARD o 11.0-ALPHA1 armv6 CUBIEBOARD2 o 11.0-ALPHA1 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA1 armv6 GUMSTIX o 11.0-ALPHA1 armv6 RPI-B o 11.0-ALPHA1 armv6 RPI2 o 11.0-ALPHA1 armv6 PANDABOARD o 11.0-ALPHA1 armv6 WANDBOARD o 11.0-ALPHA1 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA1 amd64 o 11.0-ALPHA1 i386 o 11.0-ALPHA1 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA1 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA1 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-bootonly.iso) = ad487c7eb726b74e7270e08f205ed610fefcfc6e69d8323757dc6928fb786566f18a0f3cf064b3aef07c91d6dff5791d2e317a0d606fd45a2e79282593aaf29a SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-bootonly.iso.xz) = 124298b5831d9b5c71845968b093c9c4427cef1323098e22c5d1ef85dadf8482a876664326d8c22265a72dfefda1cb46500d6a3de14fe4764222334cb43be7fe SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-disc1.iso) = 9dd2d18d4cb3ac935d14e3e2211965e606baedb8a4af2c5b39a73de918bfa8516239ff4e04170a485fb6f83f2fbd045be7d1f05d4d49210bda6059f867897da5 SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-disc1.iso.xz) = 632bbfe3da2edffca3b316edefd57098a19597ad56c9551c8ee1a47dae36d9e3e1a1958cfb9d62590f89a62302aeed4d39042f283918cdd25c4cf78ee9fe962a SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-dvd1.iso) = 5afe04bcb267ff5a17aecb8eacafa4bf11394076da9ad13c73b364e4b5ac1418502430cd1cffbad9ee01c8b4312d2c42151df7d19d279e527518520d4346e2df SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-dvd1.iso.xz) = 891c53b74c804b5dbd1045dc65b2ba1b5c302ada3746a8ae9da483822d56b153def225e87ae1e7fe942b8c9f07c281b8a5d8cdaab46f71e0825366b95a2aa168 SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-memstick.img) = 217e101f8769654953502ca85cb4a34af8896704c2e1e0035840020942e813b977b92dd596df587705c4742aa6d2ae5fc5034ddfc2071db404d02a403b6d8bbe SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-memstick.img.xz) = 8901473db12d3bb4fa76d4068fb5f19ab4b374b45636440a082e1b4d4cc63cf5c37ef168e513d5c0f04ae9dd46a99f2acf3c302ef488e614f4d2a98310198d98 SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-mini-memstick.img) = b1962d6cd66f6899b8a45b2695c965d80bb5b90f910982b510b25d7d2bf6159b5e7bcae15296f6de6b497207d7e69afae07ae5abd82f6cdd513f918e63206c7c SHA512 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-mini-memstick.img.xz) = a104c1f662a66757e64ddc60138f75ac31acc548bea386875a8b86aea307609f7c9cf88b7ffb5443f3fb4184079bb750aca435329bb2affc45e048cf1877ee10 SHA256 (FreeBSD-11.0-ALPHA1-amd64-20160528-r300895-bootonly.iso) = 009518e853f566a0d8ede802a2d6f92fc615ff88c01823e72ed90a0435412e03
Re: What builds go to snapshots?
On 2016-05-23 10:10, Sergey Manucharian wrote: > Excerpts from Allan Jude's message from Sun 22-May-16 23:55: >> On 2016-05-22 23:33, Sergey Manucharian wrote: >>> Is there any materialistic definition of those builds, which >>> become snapshots at [0]? >>> >>> - Sergey >>> >>> [0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/ >>> >> The snapshots are built with the scripts/makefiles in the 'release' >> subdirectory of the source tree. > > Thanks, Alan! But how is it determined/decided which particular build > goes to "snapshots"? E.g. the latest builds are of May 18, why not of > May 15 or 16? > > S. > That is just whenever the release engineers have time to build a snapshot. There are not usually any special considerations. -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What builds go to snapshots?
Excerpts from Allan Jude's message from Sun 22-May-16 23:55: > On 2016-05-22 23:33, Sergey Manucharian wrote: > > Is there any materialistic definition of those builds, which > > become snapshots at [0]? > > > > - Sergey > > > > [0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/ > > > The snapshots are built with the scripts/makefiles in the 'release' > subdirectory of the source tree. Thanks, Alan! But how is it determined/decided which particular build goes to "snapshots"? E.g. the latest builds are of May 18, why not of May 15 or 16? S. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What builds go to snapshots?
On 2016-05-22 23:33, Sergey Manucharian wrote: > Is there any materialistic definition of those builds, which > become snapshots at [0]? > > - Sergey > > [0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/ > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > The snapshots are built with the scripts/makefiles in the 'release' subdirectory of the source tree. -- Allan Jude ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
What builds go to snapshots?
Is there any materialistic definition of those builds, which become snapshots at [0]? - Sergey [0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Strange behaviour of getcwd for hidden ZFS snapshots.
Hi, I was trying to restore some deleted files from a snapshot with rsync: [/home/www/.zfs/snapshot/zfs-auto-snap_hourly-2015-08-31-12h00/www.tegenbosch28.nl] r...@zfs.digiware.nl# rsync -rav * /tmp rsync: getcwd(): No such file or directory (2) rsync error: errors selecting input/output files, dirs (code 3) at util.c(1101) [Receiver=3.1.1] Exit 3 Turns out that if the snapshots are hidden, then getcwd() errors out? Setting snapdir=visible on the volume gets it to do its job. As does changing out of the snapshot directory and using the full path for source and destination Is this a bug or a feature? 10.2-STABLE FreeBSD 10.2-STABLE #324 r287170: Thu Aug 27 --WjW ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
On Mon, 23 Mar 2015 10:46:32 -0700
Nathan Whitehorn wrote:
>
> On 03/23/15 09:47, Sergey V. Dyatko wrote:
> > On Mon, 23 Mar 2015 09:15:57 -0700
> > Nathan Whitehorn wrote:
> >
> >> On 03/23/15 09:06, Devin Teske wrote:
> >>>> On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
> >>>> wrote:
> >>>>
> >>>> Hi Devin,
> >>>>
> >>>> Recently I'm trying to install FreeBSD CURRENT from bootonly image
> >>>> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
> >>>> on IBM HS22 blade via bladecenter's kvm but I faced with problem on
> >>>> checksum stage, bootonly doesn't contain base, kernel,etc distributions
> >>>> but it contain manifest file.
> >>>> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
> >>>> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
> >>>> fetched files. I suppose it will be fine with RELEASE bootonly iso but
> >>>> not with stable/current.
> >>>> there is 2 ways how we can handle it:
> >>>> 1) download remote MANIFEST if spotted checksum mismatch and trying to
> >>>> use it 2) allow user to continue installation with 'broken' distributions
> >>>>
> >>>> I had to first put 10.1 then update it to HEAD :(
> >>>>
> >>>> What do you think ?
> >>> When I get some time I’ll have a look and see what I can do.
> >>> —
> >>> Cheers,
> >>> Devin
> >>>
> >>>
> >> Using the local manifest is a security feature -- there is otherwise
> >> zero protection against a man-in-the-middle attack. Ideally, you'd use
> >> the ISO that matches the posted files. There are three options here:
> >> 1. Add a dialog that lets you move ahead in the event of checksum
> >> failure, which makes me very nervous.
> >> 2. Use the boot1 disk.
> >> 2a. For release engineering: if the posted tarballs change too fast, the
> >> bootonly disk isn't actually useful for -CURRENT and should probably be
> >> removed from the FTP server.
> > I don't think so. I use only bootonly ISOs when I (rare) setup new
> > fbsd instances, disk1 contain to much useless (for me) things. I
> > haven't fast internet (in 2015, yes) so download data1 image is a pain.
>
> What useless things, out of curiousity? If you want source (which you
> probably do if you are running -CURRENT), boot1 + downloading kernel,
> base, and source code is 80% the size of disc1 for amd64. It's just not
> a huge difference.
>
~55 vs ~360 MB (FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso.xz VS
FreeBSD-11.0-CURRENT-amd64-20150302-r279514-disc1.iso.xz)
I do fetch src/ports (both HEAD) from svn so _in my case_ it is useless
(tarballs a bit outdated as minimum). Main purpose of ISOs (for me) is allow to
install minimal FreeBSD on new server. Than I can ssh into it and setup useful
stuff
> > What about STABLE images/tarballs ? If I understand correctly it is also
> > uploaded too fast...
>
> The same issue applies there, yes.
>
> >> 3. You could reroll the ISO (just untar and run makefs again),
> >> commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
> >> -Nathan
> > sure I can.
> > Idea with a dialog is a good idea, IMO :)
> >
>
> That's so@'s lookout. I'd prefer actual signatures to checksum
> verification + an option to skip.
> -Nathan
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
On 03/23/15 09:47, Sergey V. Dyatko wrote:
On Mon, 23 Mar 2015 09:15:57 -0700
Nathan Whitehorn wrote:
On 03/23/15 09:06, Devin Teske wrote:
On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
wrote:
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on
checksum stage, bootonly doesn't contain base, kernel,etc distributions
but it contain manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not
with stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use
it 2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
When I get some time I’ll have a look and see what I can do.
—
Cheers,
Devin
Using the local manifest is a security feature -- there is otherwise
zero protection against a man-in-the-middle attack. Ideally, you'd use
the ISO that matches the posted files. There are three options here:
1. Add a dialog that lets you move ahead in the event of checksum
failure, which makes me very nervous.
2. Use the boot1 disk.
2a. For release engineering: if the posted tarballs change too fast, the
bootonly disk isn't actually useful for -CURRENT and should probably be
removed from the FTP server.
I don't think so. I use only bootonly ISOs when I (rare) setup new
fbsd instances, disk1 contain to much useless (for me) things. I
haven't fast internet (in 2015, yes) so download data1 image is a pain.
What useless things, out of curiousity? If you want source (which you
probably do if you are running -CURRENT), boot1 + downloading kernel,
base, and source code is 80% the size of disc1 for amd64. It's just not
a huge difference.
What about STABLE images/tarballs ? If I understand correctly it is also
uploaded too fast...
The same issue applies there, yes.
3. You could reroll the ISO (just untar and run makefs again),
commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
-Nathan
sure I can.
Idea with a dialog is a good idea, IMO :)
That's so@'s lookout. I'd prefer actual signatures to checksum
verification + an option to skip.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
On Mon, 23 Mar 2015 09:15:57 -0700
Nathan Whitehorn wrote:
>
> On 03/23/15 09:06, Devin Teske wrote:
> >> On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
> >> wrote:
> >>
> >> Hi Devin,
> >>
> >> Recently I'm trying to install FreeBSD CURRENT from bootonly image
> >> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
> >> on IBM HS22 blade via bladecenter's kvm but I faced with problem on
> >> checksum stage, bootonly doesn't contain base, kernel,etc distributions
> >> but it contain manifest file.
> >> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
> >> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
> >> fetched files. I suppose it will be fine with RELEASE bootonly iso but not
> >> with stable/current.
> >> there is 2 ways how we can handle it:
> >> 1) download remote MANIFEST if spotted checksum mismatch and trying to use
> >> it 2) allow user to continue installation with 'broken' distributions
> >>
> >> I had to first put 10.1 then update it to HEAD :(
> >>
> >> What do you think ?
> > When I get some time I’ll have a look and see what I can do.
> > —
> > Cheers,
> > Devin
> >
> >
>
> Using the local manifest is a security feature -- there is otherwise
> zero protection against a man-in-the-middle attack. Ideally, you'd use
> the ISO that matches the posted files. There are three options here:
> 1. Add a dialog that lets you move ahead in the event of checksum
> failure, which makes me very nervous.
> 2. Use the boot1 disk.
> 2a. For release engineering: if the posted tarballs change too fast, the
> bootonly disk isn't actually useful for -CURRENT and should probably be
> removed from the FTP server.
I don't think so. I use only bootonly ISOs when I (rare) setup new
fbsd instances, disk1 contain to much useless (for me) things. I
haven't fast internet (in 2015, yes) so download data1 image is a pain.
What about STABLE images/tarballs ? If I understand correctly it is also
uploaded too fast...
> 3. You could reroll the ISO (just untar and run makefs again),
> commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
> -Nathan
sure I can.
Idea with a dialog is a good idea, IMO :)
--
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
On 03/23/15 09:06, Devin Teske wrote:
On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko wrote:
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
stage, bootonly doesn't contain base, kernel,etc distributions but it contain
manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not with
stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use it
2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
When I get some time I’ll have a look and see what I can do.
—
Cheers,
Devin
Using the local manifest is a security feature -- there is otherwise
zero protection against a man-in-the-middle attack. Ideally, you'd use
the ISO that matches the posted files. There are three options here:
1. Add a dialog that lets you move ahead in the event of checksum
failure, which makes me very nervous.
2. Use the boot1 disk.
2a. For release engineering: if the posted tarballs change too fast, the
bootonly disk isn't actually useful for -CURRENT and should probably be
removed from the FTP server.
3. You could reroll the ISO (just untar and run makefs again),
commenting out line 180 of /usr/libexec/bsdinstall/scripts/auto.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
> On Mar 22, 2015, at 10:47 PM, Sergey V. Dyatko
> wrote:
>
> Hi Devin,
>
> Recently I'm trying to install FreeBSD CURRENT from bootonly image
> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
> on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
> stage, bootonly doesn't contain base, kernel,etc distributions but it contain
> manifest file.
> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
> fetched files. I suppose it will be fine with RELEASE bootonly iso but not
> with
> stable/current.
> there is 2 ways how we can handle it:
> 1) download remote MANIFEST if spotted checksum mismatch and trying to use it
> 2) allow user to continue installation with 'broken' distributions
>
> I had to first put 10.1 then update it to HEAD :(
>
> What do you think ?
When I get some time I’ll have a look and see what I can do.
—
Cheers,
Devin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bsdinstall and current (possible stable) snapshots
On 2015-03-23 01:52, Sergey V. Dyatko wrote:
> On Mon, 23 Mar 2015 08:47:38 +0300
> "Sergey V. Dyatko" wrote:
>
>> Hi Devin,
>>
>> Recently I'm trying to install FreeBSD CURRENT from bootonly image
>> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
>> on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
>> stage, bootonly doesn't contain base, kernel,etc distributions but it contain
>> manifest file.
>> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
>> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
>> fetched files. I suppose it will be fine with RELEASE bootonly iso but not
>> with stable/current.
>> there is 2 ways how we can handle it:
>> 1) download remote MANIFEST if spotted checksum mismatch and trying to use it
>> 2) allow user to continue installation with 'broken' distributions
>>
>> I had to first put 10.1 then update it to HEAD :(
>>
>> What do you think ?
>>
>
> replying to myself :)
> possible way. #3:
> distribution filenames must contain svn revision. On checksum stage we can
> easy
> check does local MANIFEST actual or we must use remote file...
>
>
> --
> wbr, tiger
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
I have worked around this by doing:
mount -t tmpfs tmpfs /usr/freebsd-dist
This hides the MANIFEST file shipped on the bootonly image, and when
there is no local MANIFEST to compare it, it fetches one from FTP along
with the dist files, and just works.
I am unsure what the best way to handle this properly is though.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: bsdinstall and current (possible stable) snapshots
On Mon, 23 Mar 2015 08:47:38 +0300
"Sergey V. Dyatko" wrote:
> Hi Devin,
>
> Recently I'm trying to install FreeBSD CURRENT from bootonly image
> ( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
> on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
> stage, bootonly doesn't contain base, kernel,etc distributions but it contain
> manifest file.
> On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
> MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
> fetched files. I suppose it will be fine with RELEASE bootonly iso but not
> with stable/current.
> there is 2 ways how we can handle it:
> 1) download remote MANIFEST if spotted checksum mismatch and trying to use it
> 2) allow user to continue installation with 'broken' distributions
>
> I had to first put 10.1 then update it to HEAD :(
>
> What do you think ?
>
replying to myself :)
possible way. #3:
distribution filenames must contain svn revision. On checksum stage we can easy
check does local MANIFEST actual or we must use remote file...
--
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
bsdinstall and current (possible stable) snapshots
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
stage, bootonly doesn't contain base, kernel,etc distributions but it contain
manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not with
stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use it
2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
--
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Link for FreeBSD mirrors in snapshots messages
Dears All , Is it possible to include the link for FreeBSD mirrors list http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html into "New FreeBSD snapshots available : ..." messages ? This link will prevent a search of this list and will encourage use of mirrors by making it available easily . Thank you very much .. Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 10.0-BETA3 snapshots (pre -BETA4) now available
FreeBSD 10.0-BETA3 snapshots are now available. These images are generated from r258657 of stable/10, and are intended as pre -BETA4 snapshots for public testing, until 10.0-BETA4 is rolled (which should be within the next few days). Please note, freebsd-update(8) upgrades are not available for this set of builds. As these builds are considered "snapshot-only", the change list is not included, in case something needs to be reverted for the 10.0-BETA4 builds. If you notice problems you can report them through the normal GNATS PR system or here on the -current mailing list. The images may be downloaded from the 'snapshots' directory on FTP: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ In addition, pre-built virtual machine images are also available: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Checksums for the installation ISOs and the VM disk images follow at the end of this email. == ISO CHECKSUMS == - 10.0-BETA3 amd64: SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = bbaf40b51278e7f0f31ca056459539acd4eeca07eb3db77468e70f68dadfbc93 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = e3f35a786af16bf8ea7f8ba8a1ce1a4ca0aaeb4388bd1af0f5d948072768472a SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 61c8031ad3c7daafe619e686485d04ee219dc6cdec5636ac171f3e6317c37004 SHA256 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 7f8bb8e0815772a9277d8465f7b43c22b07b7dd6251ddc0809ae9309c379d743 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-bootonly.iso) = 573f679c2eacfbf46dd8452975c5a807 MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-disc1.iso) = 6ca7358887c622b7d9290da0acc4373c MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-dvd1.iso) = 833e47010f72aaed8e4ef5df8ef2f65d MD5 (FreeBSD-10.0-BETA3-amd64-20131126-r258657-memstick.img) = 576c2fc5c63aa3b3e46da38f7c40dec4 - 10.0-BETA3 i386: SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = d08bf30619af86c5c8013a64be3fe3496c6b45b522a431660617011039a966a5 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 59e98e4f91bee70d9101b04f315ea2b5e2d3650f1f203ed9bba0a9e3bea09159 SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 0680818b9bf51513a5fbf311720873207f528c6201f9b05dbe322843a83ca9de SHA256 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 7c333fd25bb9e16c9b52027b3991e96b89f5cf44bb9e6d4e5ffb2162cb5f8654 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-bootonly.iso) = 3e950d40c7f807d0a4b8eef2d85da4c5 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-disc1.iso) = 95c5deb510b2d7d89d39435210c93e90 MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-dvd1.iso) = 961394ea39d97ed706b8f840566aa7cd MD5 (FreeBSD-10.0-BETA3-i386-20131126-r258657-memstick.img) = 12366e49affc33a9104861172adab6f4 - 10.0-BETA3 ia64: SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 843d2f6c7c2c57063e0de773f98c3d6327deded9fbe7488fdd90f5d3b091399d SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 2f2b51ec6f9a32cd12db58bcb9e577f39689c250da666e7d3ceecbc54883377c SHA256 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 08902cfd3447df4edac150ff96bbf1235bab4ac461e4238c1125eea83cba15b1 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-bootonly.iso) = 876d0a31510cf6a1251324738be82177 MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-disc1.iso) = 0acf4517db5df9407e97857d7811277b MD5 (FreeBSD-10.0-BETA3-ia64-20131126-r258657-memstick.img) = 55025d6ac489769ebb251ac137fe89e7 - 10.0-BETA3 powerpc: SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = fff26c419a1a7380af4fdf8cee86aabd97584d03c6da71b2dff7e3f277f17711 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 2cdad79753ca5dc45907f14587fcfd06eed1b8449ed367f225045372762119b9 SHA256 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 16f2f54a9b7943b4eff89a8d52e96724caefecb39683125543a507a20df49953 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-bootonly.iso) = 9fb3857c394473d1e6fa7bd0753a6201 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-disc1.iso) = 4e9304f55d8a63310e4eda6c5bd8e4c7 MD5 (FreeBSD-10.0-BETA3-powerpc-20131126-r258657-memstick.img) = 11fc39cb92d9ef2d643c56368221443e - 10.0-BETA3 powerpc64: SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-bootonly.iso) = 7eb672f81d4c3cb32399f4285bb049e8576d1fabe46350210ca37bb01ea2e523 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-disc1.iso) = 3ee0949bcab657b461fa5ca9eeef82ec8cd561750e098fbfd899330178bf2337 SHA256 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-r258657-memstick.img) = df21073b158b9be8bedd8d7ed55bd385a02844234c0ecb61701a3b42b6e035bb MD5 (FreeBSD-10.0-BETA3-powerpc-powerpc64-20131126-
Re: 10-CURRENT i386 memstick snapshots broken?
On Sat, 8 Jun 2013, Glen Barber wrote: The problem is creating the gpart(8) partition scheme on the md(4) device. Below follows script(1) output of what the make-memstick.sh script does: Script started on Sun Jun 9 00:41:08 2013 root@snap:/snap/releng # chroot /snap/releng/10-i386-snap root@snap:/ # cd /usr/obj/usr/src/release root@snap:/usr/obj/usr/src/release # echo \ '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' > release/etc/fstab root@snap:/usr/obj/usr/src/release # makefs -B \ little -o label=FreeBSD_Install test.img release Calculated size of `test.img': 649420800 bytes, 12922 inodes Extent size set to 8192 test.img: 619.3MB (1268400 sectors) block size 8192, fragment size 1024 using 12 cylinder groups of 54.40MB, 6963 blks, 1152 inodes. super-block backups (for fsck -b #) at: 32, 111440, 222848, 334256, 445664, 557072, 668480, 779888, 891296, 1002704, 1114112, 1225520, Populating `test.img' Image `test.img' complete root@snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img md0 All fine up until this point. Now the gpart(8) partition is created: root@snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0 gpart: Inappropriate ioctl for device root@snap:/usr/obj/usr/src/release # gpart list md0 Segmentation fault (core dumped) This might be a good time to stop using a bare bsdlabel (aka "dangerously dedicated"). MBR plus bsdlabel is not great, but more widely understood, and other operating systems will at least recognize the MBR slice. I can help with this if needed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10-CURRENT i386 memstick snapshots broken?
On Sun, Jun 09, 2013 at 05:01:00AM +0900, Hiroki Sato wrote: > gj> Because the userland is 32-bit and the kernel is 64-bit, "something" > gj> goes wrong, but interestingly not wrong enough that the script fails > gj> entirely. So, the paritions appear to be created, but in reality, they > gj> are not. > gj> > gj> So, for the snapshots case, the solution is to write the memstick image > gj> from outside of the chroot environment, which is easy to do because > gj> I already do this for creating the VM disk images (interestingly for the > gj> same reason as the memstick creation failure). > > I do not think there is a problem with cross building in chroot. cross-building, no, there is no problem. > allbsd.org is also generating i386 snapshots on an amd64 box in > almost the same way as generate-release.sh, but the memstick images > already generated were not broken as far as I can check. Although I > do not use generate-release.sh on it because I added another build > world stage in chroot before cross compiling, the difference is > small. > > What was exactly gone wrong in 32-bit binary on 64-bit kernel? The problem is creating the gpart(8) partition scheme on the md(4) device. Below follows script(1) output of what the make-memstick.sh script does: Script started on Sun Jun 9 00:41:08 2013 root@snap:/snap/releng # chroot /snap/releng/10-i386-snap root@snap:/ # cd /usr/obj/usr/src/release root@snap:/usr/obj/usr/src/release # echo \ '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' > release/etc/fstab root@snap:/usr/obj/usr/src/release # makefs -B \ little -o label=FreeBSD_Install test.img release Calculated size of `test.img': 649420800 bytes, 12922 inodes Extent size set to 8192 test.img: 619.3MB (1268400 sectors) block size 8192, fragment size 1024 using 12 cylinder groups of 54.40MB, 6963 blks, 1152 inodes. super-block backups (for fsck -b #) at: 32, 111440, 222848, 334256, 445664, 557072, 668480, 779888, 891296, 1002704, 1114112, 1225520, Populating `test.img' Image `test.img' complete root@snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img md0 All fine up until this point. Now the gpart(8) partition is created: root@snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0 gpart: Inappropriate ioctl for device root@snap:/usr/obj/usr/src/release # gpart list md0 Segmentation fault (core dumped) I also ran into this when initially creating the 8.4-RELEASE memory stick images, which uses fdisk(8) instead of gpart(8). I basically attributed this to "probably shouldn't be expected to work", such as doing netstat(1) on within 32-bit chroot/jail on a 64-bit kernel. root@snap:/usr/obj/usr/src/release # gdb -c ./gpart.core gpart GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `gpart'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libgeom.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libgeom.so.5 Reading symbols from /lib/libsbuf.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libsbuf.so.6 Reading symbols from /lib/libbsdxml.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libbsdxml.so.4 Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/geom/geom_part.so...(no debugging symbols found)...done. Loaded symbols for /lib/geom/geom_part.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x28070205 in geom_deletetree () from /lib/libgeom.so.5 (gdb) bt #0 0x28070205 in geom_deletetree () from /lib/libgeom.so.5 #1 0x08049b43 in ?? () #2 0xcbf0 in ?? () #3 0x28813050 in ?? () #4 0x0804cb1a in ?? () #5 0x28813030 in ?? () #6 0x0804e63d in __stderrp () #7 0x in ?? () I can rebuild gpart(8) with debugging symbols enabled tomorrow. The machine is churning through builds at the moment. Glen pgpBED76ulpGg.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On Sat, Jun 08, 2013 at 02:18:48PM -0500, Nathan Whitehorn wrote: > On 06/08/13 14:17, Glen Barber wrote: > > On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote: > >> On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: > >> > >>> On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: > > Has anyone else tried the i386 memstick and having the same problem? > > > Hmm. Thanks for the report. I'll take a look at the logs for i386, but > they are generated the same way as the amd64, so in theory should not > have any noticable difference. > > >>> For amd64 and i386, native binaries are built, and installed into > >>> scratch directories; for powerpc and powerpc64, I just use the amd64 > >>> binaries, because I cannot directly use the chroot binaries for > >>> non-native architecture. > >>> > >>> The scripts chroot into the scratch directories, and run the "real" > >>> release builds. > >> Have you tried using Crochet for this sort of thing? > >> > >> Since it was designed from the ground up for cross-building > >> bootable images, it should avoid these issues. > >> > > I have not, primarily because I was not aware of crochet when > > I originally started this. Although, by using the release stuff from > > the base system, we do get a weekly run-test of the 'make release' bits > > in head/ and stable/9/, so in theory, there would be no surprises when > > it is -RELEASE time. > > > >> The only fundamental limit right now is that Crochet uses > >> the host system to build the UFS filesystems, so it can't > >> build big-endian MIPS images on i386, for example. > >> > >> > > Yes, I have this same issue with sparc64. > > > > Why not use makefs? It can build cross-endian UFS images. The scripts do (as far as I recall for sparc64) use makefs, but a port is needed to create the sparc-capable ISO image. Glen pgptKlnQa3HD9.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On 06/08/13 14:17, Glen Barber wrote: > On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote: >> On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: >> >>> On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: > Has anyone else tried the i386 memstick and having the same problem? > Hmm. Thanks for the report. I'll take a look at the logs for i386, but they are generated the same way as the amd64, so in theory should not have any noticable difference. >>> For amd64 and i386, native binaries are built, and installed into >>> scratch directories; for powerpc and powerpc64, I just use the amd64 >>> binaries, because I cannot directly use the chroot binaries for >>> non-native architecture. >>> >>> The scripts chroot into the scratch directories, and run the "real" >>> release builds. >> Have you tried using Crochet for this sort of thing? >> >> Since it was designed from the ground up for cross-building >> bootable images, it should avoid these issues. >> > I have not, primarily because I was not aware of crochet when > I originally started this. Although, by using the release stuff from > the base system, we do get a weekly run-test of the 'make release' bits > in head/ and stable/9/, so in theory, there would be no surprises when > it is -RELEASE time. > >> The only fundamental limit right now is that Crochet uses >> the host system to build the UFS filesystems, so it can't >> build big-endian MIPS images on i386, for example. >> >> > Yes, I have this same issue with sparc64. > Why not use makefs? It can build cross-endian UFS images. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10-CURRENT i386 memstick snapshots broken?
Tim Kientzle wrote in <926ef579-8ac9-4a98-8a81-4e978a627...@kientzle.com>: ti> ti> On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: ti> ti> > On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: ti> >>> Has anyone else tried the i386 memstick and having the same problem? ti> >>> ti> >> ti> >> Hmm. Thanks for the report. I'll take a look at the logs for i386, but ti> >> they are generated the same way as the amd64, so in theory should not ti> >> have any noticable difference. ti> >> ti> > ti> > For amd64 and i386, native binaries are built, and installed into ti> > scratch directories; for powerpc and powerpc64, I just use the amd64 ti> > binaries, because I cannot directly use the chroot binaries for ti> > non-native architecture. ti> > ti> > The scripts chroot into the scratch directories, and run the "real" ti> > release builds. ti> ti> Have you tried using Crochet for this sort of thing? ti> ti> Since it was designed from the ground up for cross-building ti> bootable images, it should avoid these issues. ti> ti> The only fundamental limit right now is that Crochet uses ti> the host system to build the UFS filesystems, so it can't ti> build big-endian MIPS images on i386, for example. makefs does not work? It can build BE FFS images on LE platforms. -- Hiroki pgpSfiguwNi65.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
Glen Barber wrote in <20130608173411.gd13...@glenbarber.us>: gj> On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: gj> Because the userland is 32-bit and the kernel is 64-bit, "something" gj> goes wrong, but interestingly not wrong enough that the script fails gj> entirely. So, the paritions appear to be created, but in reality, they gj> are not. gj> gj> So, for the snapshots case, the solution is to write the memstick image gj> from outside of the chroot environment, which is easy to do because gj> I already do this for creating the VM disk images (interestingly for the gj> same reason as the memstick creation failure). I do not think there is a problem with cross building in chroot. allbsd.org is also generating i386 snapshots on an amd64 box in almost the same way as generate-release.sh, but the memstick images already generated were not broken as far as I can check. Although I do not use generate-release.sh on it because I added another build world stage in chroot before cross compiling, the difference is small. What was exactly gone wrong in 32-bit binary on 64-bit kernel? -- Hiroki pgpa7n05DnipG.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On Sat, Jun 08, 2013 at 12:10:16PM -0700, Tim Kientzle wrote: > > On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: > > > On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: > >>> Has anyone else tried the i386 memstick and having the same problem? > >>> > >> > >> Hmm. Thanks for the report. I'll take a look at the logs for i386, but > >> they are generated the same way as the amd64, so in theory should not > >> have any noticable difference. > >> > > > > For amd64 and i386, native binaries are built, and installed into > > scratch directories; for powerpc and powerpc64, I just use the amd64 > > binaries, because I cannot directly use the chroot binaries for > > non-native architecture. > > > > The scripts chroot into the scratch directories, and run the "real" > > release builds. > > Have you tried using Crochet for this sort of thing? > > Since it was designed from the ground up for cross-building > bootable images, it should avoid these issues. > I have not, primarily because I was not aware of crochet when I originally started this. Although, by using the release stuff from the base system, we do get a weekly run-test of the 'make release' bits in head/ and stable/9/, so in theory, there would be no surprises when it is -RELEASE time. > The only fundamental limit right now is that Crochet uses > the host system to build the UFS filesystems, so it can't > build big-endian MIPS images on i386, for example. > > Yes, I have this same issue with sparc64. Glen pgpO68TBLrIbU.pgp Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On Jun 8, 2013, at 10:34 AM, Glen Barber wrote: > On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote: >>> Has anyone else tried the i386 memstick and having the same problem? >>> >> >> Hmm. Thanks for the report. I'll take a look at the logs for i386, but >> they are generated the same way as the amd64, so in theory should not >> have any noticable difference. >> > > For amd64 and i386, native binaries are built, and installed into > scratch directories; for powerpc and powerpc64, I just use the amd64 > binaries, because I cannot directly use the chroot binaries for > non-native architecture. > > The scripts chroot into the scratch directories, and run the "real" > release builds. Have you tried using Crochet for this sort of thing? Since it was designed from the ground up for cross-building bootable images, it should avoid these issues. The only fundamental limit right now is that Crochet uses the host system to build the UFS filesystems, so it can't build big-endian MIPS images on i386, for example. Tim signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 10-CURRENT i386 memstick snapshots broken?
On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote:
> > Has anyone else tried the i386 memstick and having the same problem?
> >
>
> Hmm. Thanks for the report. I'll take a look at the logs for i386, but
> they are generated the same way as the amd64, so in theory should not
> have any noticable difference.
>
Jimmy, thank you for reporting this. I'm honestly not quite sure how
this went unnoticed for so long.
So, basically here is what happens:
The scripts that run the weekly snapshot builds on FreeBSD.org check out
clean svn trees of head/ and stable/9 to use to "seed" chroot
environments, where the builds actually happen.
For amd64 and i386, native binaries are built, and installed into
scratch directories; for powerpc and powerpc64, I just use the amd64
binaries, because I cannot directly use the chroot binaries for
non-native architecture.
The scripts chroot into the scratch directories, and run the "real"
release builds. As Jimmy noted, the
src/release/${ARCH}/make-memstick.sh script is what generates the
memstick images. Part of that procedure is to create md(4) device, and
partition layout with gpart(8). This is where things blow up.
Because the userland is 32-bit and the kernel is 64-bit, "something"
goes wrong, but interestingly not wrong enough that the script fails
entirely. So, the paritions appear to be created, but in reality, they
are not.
So, for the snapshots case, the solution is to write the memstick image
from outside of the chroot environment, which is easy to do because
I already do this for creating the VM disk images (interestingly for the
same reason as the memstick creation failure).
Thanks to Jimmy for his patience in helping me make sure my solution
does in fact fix the problem, and the next set of 10.0-CURRENT and
9.1-STABLE i386 memsticks will not have this issue (builds are in-flight
now).
Glen
pgpueHbr_ho0d.pgp
Description: PGP signature
Re: 10-CURRENT i386 memstick snapshots broken?
On 06/07/13 22:51, Jimmy wrote: Greetings - I had originally started playing with the 10-CURRENT amd64 release a couple of months ago (no complaints here - keep up the good work!) and had used the memstick snapshot to set things up back then with no problems. Now I'd like to wipe everything and switch to the i386 version, but the memstick images (all of the last 4 or 5) seem to be broken. My machine sees that the USB stick is there, but won't boot off of it at all. When I do 'fdisk' on /dev/da0 with the i386 stuff loaded, I get a invalid partition error, so on a hunch I decided to take a closer look at the memstick images using dd if=xxx-memstick bs=512 count=1 | hd The amd64 images look like what I would expect: some bootblock code with a partition table at the end and the "a5" type marker. The i386 image, however, is ALL '00'. It would appear the whatever puts those memstick images together (src/release/i386/make-memstick.sh, perhaps?) is failing for some reason. Has anyone else tried the i386 memstick and having the same problem? Jimmy Hi, The memstick images does not contain an MBR. That's why some bioses won't boot them. You can fix this by using: fdisk -BI /dev/daX dd if=xxx.img of=/dev/daXs1 count=65536 --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10-CURRENT i386 memstick snapshots broken?
On Fri, Jun 07, 2013 at 03:51:29PM -0500, Jimmy wrote: > Greetings - > > I had originally started playing with the 10-CURRENT amd64 release > a couple of months ago (no complaints here - keep up the good work!) > and had used the memstick snapshot to set things up back then with > no problems. > > Now I'd like to wipe everything and switch to the i386 version, but > the memstick images (all of the last 4 or 5) seem to be broken. > My machine sees that the USB stick is there, but won't boot off of > it at all. When I do 'fdisk' on /dev/da0 with the i386 stuff loaded, > I get a invalid partition error, so on a hunch I decided to take a > closer look at the memstick images using > dd if=xxx-memstick bs=512 count=1 | hd > The amd64 images look like what I would expect: some bootblock code > with a partition table at the end and the "a5" type marker. The i386 > image, however, is ALL '00'. It would appear the whatever puts those > memstick images together (src/release/i386/make-memstick.sh, perhaps?) > is failing for some reason. > > Has anyone else tried the i386 memstick and having the same problem? > Hmm. Thanks for the report. I'll take a look at the logs for i386, but they are generated the same way as the amd64, so in theory should not have any noticable difference. Glen pgpXEttKEd1kP.pgp Description: PGP signature
10-CURRENT i386 memstick snapshots broken?
Greetings - I had originally started playing with the 10-CURRENT amd64 release a couple of months ago (no complaints here - keep up the good work!) and had used the memstick snapshot to set things up back then with no problems. Now I'd like to wipe everything and switch to the i386 version, but the memstick images (all of the last 4 or 5) seem to be broken. My machine sees that the USB stick is there, but won't boot off of it at all. When I do 'fdisk' on /dev/da0 with the i386 stuff loaded, I get a invalid partition error, so on a hunch I decided to take a closer look at the memstick images using dd if=xxx-memstick bs=512 count=1 | hd The amd64 images look like what I would expect: some bootblock code with a partition table at the end and the "a5" type marker. The i386 image, however, is ALL '00'. It would appear the whatever puts those memstick images together (src/release/i386/make-memstick.sh, perhaps?) is failing for some reason. Has anyone else tried the i386 memstick and having the same problem? Jimmy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Destroying ZFS snapshots "too quickly": xpt_scan_lun: can't allocate CCB, can't continue
Before the introduction of async_destroy I wrote a script to destroy ZFS snapshots in parallel to speed up the process. It's available at: http://www.fabiankeil.de/sourcecode/zfs-snapshot-destroyer/zsd.pl A couple of years ago the only downside seemed to be that it requires more memory and file descriptors (due to multiple zfs processes running at the same time) and that errors are ignored (implementation detail of the script). Recently I noticed that destroying several hundred (500) snapshots this way risks rendering the system unresponsive. I rarely do that, so it might not actually be a regression. When using X the screen freezes and keyboard input is ignored so it's hard to tell what's going on. When running the script on the console alt+Fx are often still accepted to switch consoles, but other keyboard input like entering commands or trying to login has no visible effect. A running top is killed and the system frequently logs: "xpt_scan_lun: can't allocate CCB, can't continue". Plugging in USB devices still result in the expected messages, but other than this the system seems to be unresponsive and doesn't recover (I only waited a couple of minutes, though). A "CCB" seems to be rather small: http://fxr.watson.org/fxr/source/cam/cam_xpt.c#L4386 therefore I suspect that ZFS got greedy and didn't play nice with the rest of the system. I have no proof that ZFS isn't merely triggering a problem in another subsystem, though. So far I haven't been able to reproduce the problem with snapshots intentionally created for testing, but I also used a somewhat simplistic approach to populate the snapshots. Is this considered a bug or is quickly destroying snapshots just something for the "don't do this" or "not without proper tuning" departments? I would also be interested to know if there's a way to somehow roughly figure out from userland how many snapshots can be safely destroyed in a row. Example: Look at "some" system state, destroy a safe amount of snapshots, look at "some" system state again and interpolate. Before top gets killed it usually shows that zfskern takes more than 50% WCPU, but this can also happen when the system doesn't become unresponsive and thus probably isn't a good metric (the delay also doesn't help of course). Fabian signature.asc Description: PGP signature
Re: FreeBSD 10-CURRENT and 9-STABLE snapshots
Am 10/06/12 03:32, schrieb Bruce Cran: > On 05/10/2012 15:29, Miroslav Lachman wrote: >> Unofficial snapshots can be downloaded from >> https://pub.allbsd.org/FreeBSD-snapshots/ for a long time >> (bootonly.iso too) > > I'm baffled as to why those aren't just made official. > Since a couple of time for now, the links shown on the official webpage target into void. it would be easy to replace the great void with a link to a third party with the note that it is a third party. oh signature.asc Description: OpenPGP digital signature
Re: FreeBSD 10-CURRENT and 9-STABLE snapshots
On Fri, Oct 05, 2012 at 04:29:45PM +0200, Miroslav Lachman wrote: > It would be nice to have them hosted on FreeBSD.org site as official > source. I agree 100%. > Unofficial snapshots can be downloaded from > https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso too) > I am not sure how the bootonly.iso for -CURRENT and -STABLE can point to a non-FreeBSD FTP site without patching the source prior to the release build. If there is a clean way to do this without modifying the src/ tree prior to the build phase, I am happy to also provide bootonly.iso images and the necessary hierarchy for the various distribution sets. Glen pgp9nXK033Kpl.pgp Description: PGP signature
Re: FreeBSD 10-CURRENT and 9-STABLE snapshots
On 05/10/2012 15:29, Miroslav Lachman wrote: Unofficial snapshots can be downloaded from https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso too) I'm baffled as to why those aren't just made official. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10-CURRENT and 9-STABLE snapshots
Glen Barber wrote: Hi, A number of FreeBSD users have displayed interest in the availability and testing of -STABLE and -CURRENT snapshot releases. I have been working on generating snapshots regularly, and now would like to announce their availability for those interested in testing. Please note, as always with the -STABLE and -CURRENT branches, these snapshots are not intended for production systems. The snapshots available are: - 10.0-CURRENT amd64 - 10.0-CURRENT i386 - 9.1-PRERELEASE amd64 - 9.1-PRERELEASE i386 Note that the 9.1-PRERELEASE snapshots are the stable/9 branch, not what will eventually be 9.1-RELEASE. I do not yet have snapshots for the 8-STABLE branch, but am working on the magic to make that happen as well. There are also no bootonly ISOs, since the necessary distribution sets are not available on the FreeBSD FTP servers, so I cannot direct the installer to a different location very easily. The URL for the snapshots is: https://snapshots.glenbarber.us/Latest/ It would be nice to have them hosted on FreeBSD.org site as official source. Unofficial snapshots can be downloaded from https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso too) Miroslav Lachman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 10-CURRENT and 9-STABLE snapshots
Hi, A number of FreeBSD users have displayed interest in the availability and testing of -STABLE and -CURRENT snapshot releases. I have been working on generating snapshots regularly, and now would like to announce their availability for those interested in testing. Please note, as always with the -STABLE and -CURRENT branches, these snapshots are not intended for production systems. The snapshots available are: - 10.0-CURRENT amd64 - 10.0-CURRENT i386 - 9.1-PRERELEASE amd64 - 9.1-PRERELEASE i386 Note that the 9.1-PRERELEASE snapshots are the stable/9 branch, not what will eventually be 9.1-RELEASE. I do not yet have snapshots for the 8-STABLE branch, but am working on the magic to make that happen as well. There are also no bootonly ISOs, since the necessary distribution sets are not available on the FreeBSD FTP servers, so I cannot direct the installer to a different location very easily. The URL for the snapshots is: https://snapshots.glenbarber.us/Latest/ The SHA256 of the xz(1)-compressed install medium follows, and is also included in a plain-text file on the site. FreeBSD-10.0-CURRENT-amd64-memstick.xz = 8779f5925cb903c64d647392f6af825d5e74019d6d13222045d69091b03a81ff FreeBSD-10.0-CURRENT-amd64-release.iso.xz = cc3934c947563c23f92ba1cd8ca7ded3999dfbc050e2b2647c294e442f267040 FreeBSD-10.0-CURRENT-i386-memstick.xz = 9eb7ff8e28c0c524d2794828acb601b9b7079c1d00017e3bf84b974ff4412e42 FreeBSD-10.0-CURRENT-i386-release.iso.xz = 0d1334fea13e16cb0d06a3f3c3fb7b0e1223baf06a06a889a6cffa6981348ae5 FreeBSD-9.1-PRERELEASE-amd64-memstick.xz = f5f1e7acbaaac6eb61c5194199eb6ef090af242efc9808dc1af5caeee126e15e FreeBSD-9.1-PRERELEASE-amd64-release.iso.xz = 0cfa5b258428741e0345b29eed241188d5944fcb15a70b079d39d56195f0 FreeBSD-9.1-PRERELEASE-i386-memstick.xz = 4e98ffe63b186b0e26f22c3ddfb0582019bf352d1ea39da2757817c809872b67 FreeBSD-9.1-PRERELEASE-i386-release.iso.xz = 0bce6f2a9626705484ff7cac18623f714e289ef6ddc0b6199d78eba37ded2ca4 The "Latest" directory on the site will always point to the latest batch of snapshots, which right now my goal is to regenerate every few days (I do not have a definitive timeframe in mind yet). I hope these are useful to the FreeBSD community. Feedback on this is welcome, as always. Cheers, Glen PS: Please report any issues regarding downloading to me directly. pgptJCC1nzjIf.pgp Description: PGP signature
Re: underexposed snapshots
> https://pub.allbsd.org/FreeBSD-snapshots/ i have been unable to boot i386 and am64 isos from late last week. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: underexposed snapshots
On 09/14/2012 23:43, Randy Bush wrote: > ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i > guess things are moving around. any idea where i can get the latest > tag=. I and others have brought up this issue repeatedly over the last couple of years, and the PTB have decided that since allbsd is doing it for us, we don't need to put any effort into making it happen ourselves. That in spite of the fact that numerous volunteers have come forward willing to help. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: underexposed snapshots
> As I said, this is the latest snapshot. Long story short is that the > old process was changed before 9.0 and releng hasn't caught up with > the new process yet in a sustainable manner (at least, not executing > it on a regular basis). If you have interest in making sure regular > (monthly) releases are revived, I'm sure that re@ would be more than > receptive (they're good to have, but I tried to use the new process > and quite frankly don't have the spare cycles to complete the needed > work to make things function post-9.x). if folk such as i hit barriers to testing, this does not bode well for the quality of 10.x in the long run. what is the new process? i could not find in handbook. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: underexposed snapshots
On Fri, Sep 14, 2012 at 11:55 PM, Randy Bush wrote: >>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i >>> guess things are moving around. any idea where i can get the latest >>> tag=. >> >> Latest tag is 9.1-RC1: >> ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.1-RC1/ , etc. > > this is for an i386 running 10-current As I said, this is the latest snapshot. Long story short is that the old process was changed before 9.0 and releng hasn't caught up with the new process yet in a sustainable manner (at least, not executing it on a regular basis). If you have interest in making sure regular (monthly) releases are revived, I'm sure that re@ would be more than receptive (they're good to have, but I tried to use the new process and quite frankly don't have the spare cycles to complete the needed work to make things function post-9.x). Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: underexposed snapshots
On 15-09-2012 15:43, Randy Bush wrote: > ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i > guess things are moving around. any idea where i can get the latest > tag=. https://pub.allbsd.org/FreeBSD-snapshots/ -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: underexposed snapshots
>> ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i >> guess things are moving around. any idea where i can get the latest >> tag=. > > Latest tag is 9.1-RC1: > ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.1-RC1/ , etc. this is for an i386 running 10-current randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: underexposed snapshots
On Fri, Sep 14, 2012 at 11:43 PM, Randy Bush wrote: > ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i > guess things are moving around. any idea where i can get the latest > tag=. Latest tag is 9.1-RC1: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.1-RC1/ , etc. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: underexposed snapshots
Randy Bush wrote: > ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i > guess things are moving around. any idea where i can get the latest > tag=. cut and paste error ftp://ftp.freebsd.org/pub/FreeBSD/snapshots ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
underexposed snapshots
ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i guess things are moving around. any idea where i can get the latest tag=. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FS hang when creating snapshots on a UFS SU+J setup
> First step in debugging is to find out if the problem is SU+J > specific. To find out, turn off SU+J but leave SU. This change > is done by running: > > umount > tunefs -j disable > mount > cd > rm .sujournal Success! Thanks Mr. McKusick. I posted having this problem to the FreeBSD forum http://forums.freebsd.org/showthread.php?t=25787, but wanted to emphasize that in two VirtualBox VMs that were created in exactly the same way, the dump issue didn't occur in the absolutely fresh FreeBSD-9.0 install (not even portsnap yet), but it did occur in the system I had installed some ports on (an Apache/MySQL/Python stack, a few additional GNU build tools, and some other miscellaneous ports). I don't know if this means anything, just hoping it might help - presumably SU+J would be a good thing. ;) Regards, Dale ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FS hang when creating snapshots on a UFS SU+J setup
On Wed, Jan 11, 2012 at 11:12:35PM +0530, Gautam Mani wrote: > > Do let me know if I can try something further. > I reproduced this again and here is the core.txt crash summary if it helps. http://pastebin.com/hTGMXX6A Thanks Gautam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FS hang when creating snapshots on a UFS SU+J setup
On Wed, Jan 11, 2012 at 10:30:39AM +0100, Yamagi Burmeister wrote: > Hello, > I've done some tests to verify that the problem only occures when SU+J > is used, but not SU without J. In fact, I did run the following two > loops on different TTYs in parallel: I also confirm this using a similar technique. The panic is only seen with SU+J and not with just SU. I did a similar cp -R /root /var/tmp ; rm -rf /var/tmp/root and the panic was trigger with dump -0L... I got the panic (again in less than a minute of issuing the dump command) -- I also got the "giving up on dirty" kind of message. I took a picture of the screen -- I am not sure if that helps! http://picpaste.com/11012012519-LF0sWlpw.jpg > Since it's much more likely that the problems described above arrise > when the the filesystem is loaded (for example by the first loop) while > taking the snapshot this looks like some kind of race condition or > something like that. > Earlier I have seen this happen with dump without any high load -- or atleast very minimum -- again with the /var because some logs were written or cronjob was running writing to it. That didnt panic as I indicated in my previous email -- hogged the CPU and forced a power-cycle. Do let me know if I can try something further. Thanks Gautam ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FS hang when creating snapshots on a UFS SU+J setup
Hello, I've done some tests to verify that the problem only occures when SU+J is used, but not SU without J. In fact, I did run the following two loops on different TTYs in parallel: while 1 cp -r /usr/src /root rm -Rf /root/src end while 1 mksnap_ffs / /.snap/snap rm -f /.snap/snap end With SU without J the system survives this for at least 1 hour. But as soon as SU+J is used it most likely deadlocks or even panics in the first 1 or 2 minutes. What extactly happens seems to vary... In most cases the system just deadlocks, sometimes like al...@bsdgate.org descripes and sometimes it's completely unresponsive to any input. I've seen kernel messages like "fsync: giving up on dirty". Several times the system paniced. In most cases printing the generic "panic: page fault while in kernel mode" and one time printing "panic: snapacct_ufs2: bad block". I've never seen the same backtrace twice. One time the system suddenly rebooted, like a tripple fault or something like that happend. Since it's much more likely that the problems described above arrise when the the filesystem is loaded (for example by the first loop) while taking the snapshot this looks like some kind of race condition or something like that. Some more information from an older debug session can be found at: http://deponie.yamagi.org/freebsd/debug/snapshots_panic/ On Tue, 10 Jan 2012 10:30:13 -0800 Kirk McKusick wrote: > > Date: Mon, 9 Jan 2012 18:30:51 +0100 > > From: Yamagi Burmeister > > To: j...@freebsd.org, mckus...@freebsd.org > > Cc: freebsd-current@freebsd.org, br...@bryce.net > > Subject: Re: FS hang when creating snapshots on a UFS SU+J setup > > > > Hello, > > > > I'm sorry to bother you, but you may not be aware of this thread and > > this problem. We are several people experiencing deadlocks, kernel > > panics and other problems when creating sanpshots on file systems > > with SU+J. It would be nice to get some feedback, e.g. how can we > > help debugging and / or fixing this problem. > > > > Thank you, > > Yamagi > > First step in debugging is to find out if the problem is SU+J > specific. To find out, turn off SU+J but leave SU. This change > is done by running: > > umount > tunefs -j disable > mount > cd > rm .sujournal > > You may want to run `fsck -f' on the filesystem while you have > it unmounted just to be sure that it is clean. Then run your > snapshot request to see if it still fails. If it works, then > we have narrowed the problem down to something related to SU+J. > If it fails then we have a broader issue to deal with. > > If you wish to go back to using SU+J after the test, you can > reenable SU+J by running: > > umount > tunefs -j enable > mount > > When responding to me, it is best to use my > email as I tend to read it more regularly. > > Kirk McKusick > -- Homepage: www.yamagi.org XMPP: yam...@yamagi.org GnuPG/GPG: 0xEFBCCBCB pgpCLdO5w7GlU.pgp Description: PGP signature
Re: FS hang when creating snapshots on a UFS SU+J setup
Le mar 10/01/12 19:30, "Kirk McKusick" mckus...@mckusick.com a écrit: > > Date: Mon, 9 Jan 2012 18:30:51 +0100 > > From: Yamagi Burmeister .org> > To: jeff@freebsd > .org, mckusick > @freebsd.org > Cc: f > reebsd-curr...@freebsd.org, bryce@bryce.n > et > Subject: Re: FS hang when creating snapshots on a > UFS SU+J setup > > > Hello, > > > > I'm sorry to bother you, but you may not be aware of > this thread and > this problem. We are several people experiencing > deadlocks, kernel > panics and other problems when creating sanpshots on > file systems > with SU+J. It would be nice to get some feedback, > e.g. how can we > help debugging and / or fixing this > problem. > > > Thank you, > > Yamagi > > First step in debugging is to find out if the problem is SU+J > specific. To find out, turn off SU+J but leave SU. This change > is done by running: > > umount > tunefs -j disable > mount > cd > rm .sujournal > > You may want to run `fsck -f' on the filesystem while you have > it unmounted just to be sure that it is clean. Then run your > snapshot request to see if it still fails. If it works, then > we have narrowed the problem down to something related to SU+J. > If it fails then we have a broader issue to deal with. > > If you wish to go back to using SU+J after the test, you can > reenable SU+J by running: > > umount > tunefs -j enable > mount > > When responding to me, it is best to use my k...@mckusick.com> email as I tend to read it more regularly. > > Kirk McKusick > ___ > f > reebsd-curr...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > Hi, Agree that i wasn't disable journaling completely before doing a clean full FSCK. Taking actions requested, i wasn't able to recover this race condition with SUJ. but snapshot still OK with only SU : So here are some few investigations i have taken: (Sorry being too long) This test system was freshly installed by ISO 9.0 RC1 (18 OCTOBER / after the fix) and is csuped on 9_RELENG (40G avail) very basic setup, just dovecot running, on GENERIC. Operations and results: Since it's the rootfs: Clean shutdown, boot single, disable SUJ, mount in RW and remove the .sujournal and the bad snapshots file, clean halt. I reboot in single again, then fsck_ufs -y /dev/ufs/ROOTFS I got some very minor fixup with freeblock count wrong and summary information bad and BLK missing in bitmaps. After a normal reboot, issue a successful snapshot without softupdate journaling just su. I reboot in single again, and reactivate SUJ then reboot in normal mode. Issue snapshot: and again mksnap_ffs eating all cpu, not suspendable, not killable. So i try to figure out what's going on: with systat -v / gstat / top -SCHP and strace / truss / ktrace on ramfs and nfs for tracking mksanp_ffs: Here some results: gstat : 26 seconds intense io activity: like normal snapshot. Bad spare snapshot file created ( UFS label (ROOTFS) not present and some garbage on the beginning. real and sparse size of file 'very' near to a normal snapshot file. Truss begin showing info then hang before being usefull. mksnap_ffs is in running / runnable mode eating 100% cpu in kernel mode, 0% in user mode. systat : hang top still running correctly : 15 to 25 % CPU in interrupt SWI4 : CLOCK ( CPU 2 cores ) strace : only for i386 :-( ktrace: block before showing valuable info, even on remote nfs. regular process hanging on suspfs. hard power cycle: After normal reboot , after regular SUJ FIXUP: Got Panic at the login prompt: ( bg_fsck not started ) panic: ffs_sync: rofs mod ( it's physical machine , no screen shots, ) backtrace show ffs_write_suspend+0x...before the ffs_sync So i retry to reboot with the 9 RC1 CD in live mode, disable suj, disable su, fsck, renable su, suj, mount the fs,without doing something on it, issue a snapshot ( still in live mode) , and this time, the snapshot was OK even with SUJ. So i wrongly figure out that touching the root fs in single user is not as best as touching it with a live CD. But after returning in normal operation, this race is still there. After various tracking tests, and rebooting in normal mode after the SUJ standard recovery: I sometime got a double panic after the login prompt panic:ffs_blkfree_cg and just after the backtrace softdep_process_worklist ... -> panic: bufwrite: bufwrite is not busy. I also saw, when there is more io activity while taking snapshot, a kernel panic saying: panic: softdep_deallocate_dependencies: dangling deps Sure something wrong in this setup, because SUJ snapsho
Re: FS hang when creating snapshots on a UFS SU+J setup
> Date: Mon, 9 Jan 2012 18:30:51 +0100 > From: Yamagi Burmeister > To: j...@freebsd.org, mckus...@freebsd.org > Cc: freebsd-current@freebsd.org, br...@bryce.net > Subject: Re: FS hang when creating snapshots on a UFS SU+J setup > > Hello, > > I'm sorry to bother you, but you may not be aware of this thread and > this problem. We are several people experiencing deadlocks, kernel > panics and other problems when creating sanpshots on file systems > with SU+J. It would be nice to get some feedback, e.g. how can we > help debugging and / or fixing this problem. > > Thank you, > Yamagi First step in debugging is to find out if the problem is SU+J specific. To find out, turn off SU+J but leave SU. This change is done by running: umount tunefs -j disable mount cd rm .sujournal You may want to run `fsck -f' on the filesystem while you have it unmounted just to be sure that it is clean. Then run your snapshot request to see if it still fails. If it works, then we have narrowed the problem down to something related to SU+J. If it fails then we have a broader issue to deal with. If you wish to go back to using SU+J after the test, you can reenable SU+J by running: umount tunefs -j enable mount When responding to me, it is best to use my email as I tend to read it more regularly. Kirk McKusick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FS hang when creating snapshots on a UFS SU+J setup
Hello,
I'm sorry to bother you, but you may not be aware of this thread and
this problem. We are several people experiencing deadlocks, kernel
panics and other problems when creating sanpshots on file systems
with SU+J. It would be nice to get some feedback, e.g. how can we
help debugging and / or fixing this problem.
Thank you,
Yamagi
On Mon, 2 Jan 2012 23:27:57 -0600
Bryce Edwards wrote:
> I have a RELENG_9 machine that hangs when a snapshot is created on the
> root fs (UFS, with SU+J). More accurately, all the processes show a
> state of "suspfs" (with ^T) and no fs activity is completed from then
> on. A hard reboot (power cycle) was the only way to proceed.
>
> Here's some reference info - let me know what else I should provide.
>
> $uname -a
> FreeBSD xxx.xxx.net 9.0-PRERELEASE FreeBSD 9.0-PRERELEASE #0: Sun Dec
> 25 05:04:37 UTC 2011 r...@xxx.xxx.net:/usr/obj/usr/src/sys/GENERIC
> amd64
>
> csup was run just before build[world|kernel] so you have reference on
> the version information.
>
> $mount
> /dev/gpt/root on / (ufs, local, journaled soft-updates)
> devfs on /dev (devfs, local, multilabel)
> linprocfs on /compat/linux/proc (linprocfs, local)
> { zfs info removed }
>
> $df -h
> Filesystem Size Used Avail Capacity Mounted on
> /dev/gpt/root 454G 9.1G 409G 2% /
> devfs 1.0k 1.0k 0B 100% /dev
> linprocfs 4.0k 4.0k 0B 100% /compat/linux/proc
> { zfs info removed }
>
> After the hard reset, there was a snapshot file listed in /.snap and
> it was ~465 GB, iirc. Unfortunately, I needed to get things going
> again so I was not able to debug or diagnose further. I may be able
> to schedule a time that I could recreate the issue and diagnose
> better, but I wanted to get your input on what data points and/or
> command you would be interested in.
>
> Thanks in advance,
>
> Bryce
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Homepage: www.yamagi.org
XMPP: yam...@yamagi.org
GnuPG/GPG: 0xEFBCCBCB
pgpjO4CjwHfj4.pgp
Description: PGP signature
