Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?
On 2021-Dec-09 08:19:30 +0100, Emmanuel Vadot wrote: > > Hi Mark, > >On Wed, 8 Dec 2021 20:36:20 -0800 >Mark Millard via freebsd-current wrote: > >> [ Note: w...@freebsd.org is only a guess, based on: >> https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html >> ] >> >> Attempting to update to: >> >> main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 >> >> resulted in boot failure (showing some boot -v output): [hang just before root is mounted] > Could you try reverting >8661e085fb953855dbc7059f21a64a05ae61b22c "mmc: Fix HS200/HS400 >capability check" and let me know ? I had exactly the same boot failure but was still working backwards through the root mount code trying to isolate the issue. Reverting 8661e085fb953855dbc7059f21a64a05ae61b22c solves the problem for me. I'd noticed the mmc1 difference and mmcsd1 error: mmc1: bus: 8bit, 200MHz (HS200 timing) mmc1: memory: 30310400 blocks, erase sector 1024 blocks mmc1: setting transfer rate to 150.000MHz (HS200 timing) bud I didn't think it was the cause. I had tracked down that the hang was somewhere between https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n779 and https://cgit.freebsd.org/src/tree/sys/kern/vfs_mountroot.c#n1008 which led me to suspect that the problem might be in the geom layer (eg g_waitidle()) but was still considering where to add my next tranche of printf's when I saw Mark's mail. -- Peter Jeremy signature.asc Description: PGP signature
Re: Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?
Hi Mark, On Wed, 8 Dec 2021 20:36:20 -0800 Mark Millard via freebsd-current wrote: > [ Note: w...@freebsd.org is only a guess, based on: > https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html > ] > > Attempting to update to: > > main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 > > resulted in boot failure (showing some boot -v output): > > . . . > mmc0: Probing bus > . . . > mmc0: SD probe: failed > mmc0: MMC probe: OK (OCR: 0x40ff8080) > mmc0: Current OCR: 0x00ff8080 > mmc0: Probing cards > mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x > mmc0: quirks: 0 > mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks > mmc0: setting transfer rate to 150.000MHz (HS200 timing) > mmcsd0: taking advantage of TRIM > mmcsd0: cache size 65536KB > mmcsd0: 125GB at mmc0 > 150.0MHz/8bit/1016-block > mmcsd0boot0: 4MB partition 1 at mmcsd0 > mmcsd0boot1: 4MB partition 2 at mmcsd0 > mmcsd0rpmb: 4MB partition 3 at mmcsd0 > . . . > Release APs...done > regulator: shutting down unused regulators > GEOM: new disk mmcsd0 > regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 > busy > GEOM: new disk mmcsd0boot1 > Trying to mount root from ufs:/dev/gpt/Rock64root []... > Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > mmcsd0: Error indicated: 4 Failed > > Note the the above line. It seems to be unique to > the failure. Continuing the output . . . > > uhub2: 1 port with 1 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub0: 1 port with 1 removable, self powered > uhub3: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub1 > umass0: on > usbus4 > umass0: SCSI over Bulk-Only; quirks = 0x > umass0:0:0: Attached to scbus0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-4 SCSI device > da0: Serial Number REPLACED > da0: 400.000MB/s transfers > da0: 953869MB (1953525168 512 byte sectors) > da0: quirks=0x2 > da0: Delete methods: > > Nothing more after that. > > An older kernel (1400042) that happened to be available boots > the same configuration when used instead (same world) . . . > > main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: > > mmc0: Probing bus > . . . > mmc0: SD probe: failed > mmc0: MMC probe: OK (OCR: 0x40ff8080) > mmc0: Current OCR: 0x00ff8080 > mmc0: Probing cards > mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) > mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) > mmc0: Card at relative address 0x0002 added: > mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x > mmc0: quirks: 0 > mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) > mmc0: memory: 244277248 blocks, erase sector 1024 blocks > mmc0: setting transfer rate to 52.000MHz (high speed timing) > > Note the lack of trying "150.000MHz (HS200 timing)". Continuing > the output . . . > > mmc0: setting bus width to 8 bits high speed timing > mmcsd0: taking advantage of TRIM > mmcsd0: cache size 65536KB > mmcsd0: 125GB at mmc0 > 52.0MHz/8bit/1016-block > mmcsd0boot0: 4MB partition 1 at mmcsd0 > mmcsd0boot1: 4MB partition 2 at mmcsd0 > mmcsd0rpmb: 4MB partition 3 at mmcsd0 > > Note: The media is actually an e.MMC . Continuing the output . . . > > . . . > Release APs...done > regulator: shutting down unused regulators > GEOM: new disk mmcsd0 > regulator: shutting down vcc_sd... Trying to mount root from > ufs:/dev/gpt/Rock64root []... > GEOM: new disk mmcsd0boot0 > busy > GEOM: new disk mmcsd0boot1 > Unresolved linked clock found: hdmi_phy > Unresolved linked clock found: usb480m_phy > Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM > uhub1: 1 port with 1 removable, self powered > uhub0: 2 ports with 2 removable, self powered > uhub3: 1 port with 1 removable, self powered > uhub2: 1 port with 1 removable, self powered > ugen4.2: at usbus4 > umass0 on uhub0 > umass0: on > usbus4 > umass0: SCSI over Bulk-Only; quirks = 0x > umass0:0:0: Attached to scbus0 > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > Root mount waiting for: CAM > GEOM: new disk da0 > pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > pass0: Fixed Direct Access SPC-4 SCSI device > pass0: Serial Number REPLACED > pass0: 400.000MB/s transfers > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: Fixed
Rock64 configuration fails to boot for main 22c4ab6cb015 but worked for main 06bd74e1e39c (Nov 21): e.MMC mishandled?
[ Note: w...@freebsd.org is only a guess, based on: https://lists.freebsd.org/archives/dev-commits-src-main/2021-December/001931.html ] Attempting to update to: main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 resulted in boot failure (showing some boot -v output): . . . mmc0: Probing bus . . . mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x mmc0: quirks: 0 mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks mmc0: setting transfer rate to 150.000MHz (HS200 timing) mmcsd0: taking advantage of TRIM mmcsd0: cache size 65536KB mmcsd0: 125GB at mmc0 150.0MHz/8bit/1016-block mmcsd0boot0: 4MB partition 1 at mmcsd0 mmcsd0boot1: 4MB partition 2 at mmcsd0 mmcsd0rpmb: 4MB partition 3 at mmcsd0 . . . Release APs...done regulator: shutting down unused regulators GEOM: new disk mmcsd0 regulator: shutting down vcc_sd... GEOM: new disk mmcsd0boot0 busy GEOM: new disk mmcsd0boot1 Trying to mount root from ufs:/dev/gpt/Rock64root []... Unresolved linked clock found: hdmi_phy Unresolved linked clock found: usb480m_phy mmcsd0: Error indicated: 4 Failed Note the the above line. It seems to be unique to the failure. Continuing the output . . . uhub2: 1 port with 1 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub0: 1 port with 1 removable, self powered uhub3: 1 port with 1 removable, self powered ugen4.2: at usbus4 umass0 on uhub1 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0: Attached to scbus0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 400.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=0x2 da0: Delete methods: Nothing more after that. An older kernel (1400042) that happened to be available boots the same configuration when used instead (same world) . . . main-n250903-06bd74e1e39c-dirty: Sun Nov 21 23:02:57 PST 2021 got: mmc0: Probing bus . . . mmc0: SD probe: failed mmc0: MMC probe: OK (OCR: 0x40ff8080) mmc0: Current OCR: 0x00ff8080 mmc0: Probing cards mmc0: New card detected (CID 150100444a4e423452079f43b2ae6313) mmc0: New card detected (CSD d02701320f5903fff6dbffef8e40400d) mmc0: Card at relative address 0x0002 added: mmc0: card: MMCHC DJNB4R 0.7 SN REPLACED MFG 06/2016 by 21 0x mmc0: quirks: 0 mmc0: bus: 8bit, 200MHz (HS400 with enhanced strobe timing) mmc0: memory: 244277248 blocks, erase sector 1024 blocks mmc0: setting transfer rate to 52.000MHz (high speed timing) Note the lack of trying "150.000MHz (HS200 timing)". Continuing the output . . . mmc0: setting bus width to 8 bits high speed timing mmcsd0: taking advantage of TRIM mmcsd0: cache size 65536KB mmcsd0: 125GB at mmc0 52.0MHz/8bit/1016-block mmcsd0boot0: 4MB partition 1 at mmcsd0 mmcsd0boot1: 4MB partition 2 at mmcsd0 mmcsd0rpmb: 4MB partition 3 at mmcsd0 Note: The media is actually an e.MMC . Continuing the output . . . . . . Release APs...done regulator: shutting down unused regulators GEOM: new disk mmcsd0 regulator: shutting down vcc_sd... Trying to mount root from ufs:/dev/gpt/Rock64root []... GEOM: new disk mmcsd0boot0 busy GEOM: new disk mmcsd0boot1 Unresolved linked clock found: hdmi_phy Unresolved linked clock found: usb480m_phy Root mount waiting for: usbus1 usbus2 usbus3 usbus4 CAM uhub1: 1 port with 1 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered ugen4.2: at usbus4 umass0 on uhub0 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x umass0:0:0: Attached to scbus0 Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM GEOM: new disk da0 pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SPC-4 SCSI device pass0: Serial Number REPLACED pass0: 400.000MB/s transfers da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number REPLACED da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors) da0: quirks=0x2 da0: Delete methods: random: unblocking device. Warning: bad time from time-of-day clock, system time will not be set accurately Dual Console: Serial Primary, Video Secondary start_init: trying /sbin/init . . . (I'll stop with
new boot message: "/etc/rc: WARNING: $zfskeys_enable is not set properly - see rc.conf(5)."?
As of my update to (some line splitting applied): # uname -apKU FreeBSD CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #25 main-n251456-22c4ab6cb015-dirty: Tue Dec 7 19:38:53 PST 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400043 1400043 my boot sequences are getting a report of: # dmesg -a | grep zfsk /etc/rc: WARNING: $zfskeys_enable is not set properly - see rc.conf(5). for the likes of a system (aarch64 example) based on: # gpart show =>40 2000409184 ada0 GPT (954G) 40 409600 1 efi (200M) 409640 1740636160 2 freebsd-ufs (830G) 1741045800 117440512 3 freebsd-swap (56G) 1858486312 134217728 4 freebsd-swap (64G) 1992704040 7705184- free - (3.7G) But I also get the notice for a system (aarch64 again) based on: # gpart show =>40 1875384928 nda1 GPT (894G) 40 532480 1 efi (260M) 5325202008- free - (1.0M) 534528 515899392 2 freebsd-swap (246G) 51643392020971520- free - (10G) 537405440 1337979528 3 freebsd-zfs (638G) The amd64 system gets the same message. The note to see rc.conf(5) is misleading for main 22c4ab6cb015 : # man 5 rc.conf | grep zfsk # === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
W dniu 3.12.2021 o 14:54, Jeffrey Bouquet pisze: On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote: On 03/12/2021 12:52, Yetoo Happy wrote: [...] Thank you Yetoo for describing your experience, bringing the topic again and provoking this discussion. Quick Start* and follow the instructions and get to step 7 and may think that even though etcupdate is different from mergemaster from the last time they used the handbook they have faith that following the instructions won't brick their system. This user will instead find that faith in general is just a very complex facade for the pain and suffering of not following *24.5.6.1 Merging Configuration Files* because the user doesn't know that step exists or relevant to the current step and ends up unknowingly having etcupdate append " yours ... > new" to the top of the user's very important configuration files that they didn't expect the program to actually modify that way when they resolved differences nor could they predict easily because the diff format is so unintuitive and different from mergemaster. Now unable to login or boot into single user mode because redirections instead of the actual configuration is parsed the user goes to the handbook to find out what might have happened and scrolls down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. [...] That's why I think etcupdate is not so intuitive as tool like this should be and etcupdate is extremely dangerous because it intentionally breaks syntax of files vital to have system up and running. If anything goes wrong with mergemaster automatic process then your have configuration not updated which is almost always fine to boot the system and fix it. But after etcupdate? Much worse... I maintain about 30 machines for 2 decades and had problems with etcupdate many times. I had ti use mergemaster as fall back many times. Mainly because of etcupdate said "Reference tree to diff against unavailable" or "No previous tree to compare against, a sane comparison is not possible.". And sometimes because etcupdate cannot automatically update many files in /etc/rc.d and manual merging of a lot of files with " " is realy painful while with mergemaster only simple keyboard shortcuts will solve it. All of this must be very stressful for beginners. So beside the update of documentation I really would like to see some changes to etcupdate workflow where files are modified in temporary location and moved to destination only if they do not contain any syntax breaking changes like , , . Kind regards Miroslav Lachman Agree. I fell back to mergemaster this Nov on 13-stable when the /var files pertaining to etcupdate were all missing current /etc data, and no study of man etcupdate was clear enough to rectify such a scenario, and suspect my initial use of etcupdate will or may require a planned reinstall, not having had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and I am just hoping mergemaster stays in /usr/src and updated So do I. for system changes, even if moved to 'tools' or something, since its use seems intuitive and much less of a black box. Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. Some people are pushing toward etcupdate(8) for the automation and 3-way merge support, but updating old STABLE with this tool could be really stressful and time-consuming challenge. How would one for example find old sources to perform "etcupdate extract" ? From my experience etcupdate(8) is only useful for updating RELEASEs or frequently updated CURRENT. The power of sdiff(1) way merge giving full control over the update process is the real strength of cursed mergemaster(8). Maybe it's a barrier for people not familiar with vi(1) and requires more time per update, but so far never failed me. The missing $FreeBSD ...$ IDs can be regenerated in local git repo with smudge filters. Generating locally these IDs for the specific set of files which mergemaster(8) operates on doesn't slow down the repository and shouldn't be considered as argument for deprecation and removal of mergemaster(8). I tried to use etcupdate(8) for STABLE a few times, but the ricochet shot my foot once or twice, so stepped back. I still maintain what I have written earlier, that a well-worn hammer could be in some cases better than a nailgun. Biased, 20+ years FreeBSD and mergemaster(8) user, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
On Wed, 8 Dec 2021 09:11:05 -0800 John Baldwin wrote: > On 12/3/21 6:09 PM, Tomoaki AOKI wrote: > > On Fri, 03 Dec 2021 05:54:37 -0800 (PST) > > "Jeffrey Bouquet" wrote: > > > >> > >> > >> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> > >> wrote: > >> > >>> On 03/12/2021 12:52, Yetoo Happy wrote: > >>> > >>> [...] > >>> > Quick Start* and follow the instructions and get to step > 7 and may think that even though etcupdate is different from mergemaster > from the last time they used the handbook they have faith that following > the instructions won't brick their system. This user will instead find > that > faith in general is just a very complex facade for the pain and suffering > of not following *24.5.6.1 Merging Configuration Files* because the user > doesn't know that step exists or relevant to the current step and ends up > unknowingly having etcupdate append " yours ... > new" to the top > of the user's very important configuration files that they didn't expect > the program to actually modify that way when they resolved differences > nor > could they predict easily because the diff format is so unintuitive and > different from mergemaster. Now unable to login or boot into single user > mode because redirections instead of the actual configuration is parsed > the > user goes to the handbook to find out what might have happened and > scrolls > down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. > >>> > >>> [...] > >>> > >>> That's why I think etcupdate is not so intuitive as tool like this > >>> should be and etcupdate is extremely dangerous because it intentionally > >>> breaks syntax of files vital to have system up and running. > >>> If anything goes wrong with mergemaster automatic process then your have > >>> configuration not updated which is almost always fine to boot the system > >>> and fix it. But after etcupdate? Much worse... > >>> > >>> I maintain about 30 machines for 2 decades and had problems with > >>> etcupdate many times. I had ti use mergemaster as fall back many times. > >>> Mainly because of etcupdate said "Reference tree to diff against > >>> unavailable" or "No previous tree to compare against, a sane comparison > >>> is not possible.". And sometimes because etcupdate cannot automatically > >>> update many files in /etc/rc.d and manual merging of a lot of files with > >>> " " is realy painful while with mergemaster only simple > >>> keyboard shortcuts will solve it. > >>> All of this must be very stressful for beginners. > >>> > >>> So beside the update of documentation I really would like to see some > >>> changes to etcupdate workflow where files are modified in temporary > >>> location and moved to destination only if they do not contain any syntax > >>> breaking changes like , , . > >>> > >>> Kind regards > >>> Miroslav Lachman > >> > >> > >> Agree. I fell back to mergemaster this Nov on 13-stable when the /var files > >> pertaining to etcupdate were all missing current /etc data, and no study of > >> man etcupdate was clear enough to rectify such a scenario, and suspect my > >> initial use of etcupdate will or may require a planned reinstall, not > >> having > >> had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and > >> I am just hoping mergemaster stays in /usr/src and updated > >> for system changes, even if moved to 'tools' or > >> something, since its use seems intuitive and much less of a black box. > >> Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. > >> > > > > Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run) > > option of etcupdate is now quite harmful. Maybe by any commit done in > > this april on main (MFC'ed to stable/13 in june). > > > > *I got busy manually checking and applying changes to /etc, and > >forgot to file PR. > > > > Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does > > NOT do anything, hence nothing is actually updated. > > The only workaround I have is NOT to try dry-run. > > Humm. > > > It would be because the same trees are used for dry-run and actual run. > > (Not looked into the code. Just a thought.) > > So the new changes always build a temporary tree (vs trying to build > /var/db/etupdate/current in place). For -n it should be that it just > doesn't change /var/db/etcupdate/current at the end, but if it did the > move anyway that would explain the bug you are seeing. That does indeed > look broken. Please file a PR as a reminder for me to fix it. > > -- > John Baldwin > Done. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260281 -- Tomoaki AOKI
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
If it was in a temporary directory, even if I manaually resolved the file and merge, I was expecting that file marked as resolve to stay in that temporary directory until I was done with all my files. Maybe I'm confusing mergemaster -Ui behavior with something else, but it seems like only merging after the user has reviewed all manual changes in a final verification sweep is common sense or at least explicitly display the tree directory that would be written to and say this is final change. I didn't know that each file etcupdate went over was going to be the final review. I think my system broke by the time I got to the rest of the postponed items due to this. On Wed, Dec 8, 2021, 9:05 AM John Baldwin wrote: > On 12/3/21 4:58 AM, Miroslav Lachman wrote: > > So beside the update of documentation I really would like to see some > > changes to etcupdate workflow where files are modified in temporary > > location and moved to destination only if they do not contain any syntax > > breaking changes like , , . > > This is what etcupdate does, so I'm a bit confused why you are getting > merge markers in /etc. When an automated 3-way merge doesn't work due > to conflicts, the file with the conflicts is saved in > /var/db/etcupdate/conflicts/. It is only copied to /etc when you > mark it as fully resolved when running 'etcupdate resolve'. Perhaps > you had multiple conflicts in a modified file and when editing the file > you only fixed the first one and then marked it as resolved at the > prompt? Even in that case etcupdate explicitly prompts you a second time > after you say "r" with "File still has conflicts, are you sure?", > so it will only install a file to /etc with those changes if you have > explicitly confirmed you want it. > > -- > John Baldwin >
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
Am 08.12.21 um 18:11 schrieb John Baldwin: > So the new changes always build a temporary tree (vs trying to build > /var/db/etupdate/current in place). For -n it should be that it just > doesn't change /var/db/etcupdate/current at the end, but if it did the > move anyway that would explain the bug you are seeing. That does indeed > look broken. Please file a PR as a reminder for me to fix it. If you work on this then please have a look at PR 247519, too: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247519 This problem lead to my complete customized /etc getting lost when I invoked etcupdate with WITH_DIRDEPS_BUILD defined in /etc/src-env.conf. But I can imagine other reasons that let the make commands in build_tree() fail without error exit, leading to an empty etcupdate/current tree and subsequent deletion of files in /etc. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
On 12/3/21 6:09 PM, Tomoaki AOKI wrote: On Fri, 03 Dec 2021 05:54:37 -0800 (PST) "Jeffrey Bouquet" wrote: On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote: On 03/12/2021 12:52, Yetoo Happy wrote: [...] Quick Start* and follow the instructions and get to step 7 and may think that even though etcupdate is different from mergemaster from the last time they used the handbook they have faith that following the instructions won't brick their system. This user will instead find that faith in general is just a very complex facade for the pain and suffering of not following *24.5.6.1 Merging Configuration Files* because the user doesn't know that step exists or relevant to the current step and ends up unknowingly having etcupdate append " yours ... > new" to the top of the user's very important configuration files that they didn't expect the program to actually modify that way when they resolved differences nor could they predict easily because the diff format is so unintuitive and different from mergemaster. Now unable to login or boot into single user mode because redirections instead of the actual configuration is parsed the user goes to the handbook to find out what might have happened and scrolls down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6. [...] That's why I think etcupdate is not so intuitive as tool like this should be and etcupdate is extremely dangerous because it intentionally breaks syntax of files vital to have system up and running. If anything goes wrong with mergemaster automatic process then your have configuration not updated which is almost always fine to boot the system and fix it. But after etcupdate? Much worse... I maintain about 30 machines for 2 decades and had problems with etcupdate many times. I had ti use mergemaster as fall back many times. Mainly because of etcupdate said "Reference tree to diff against unavailable" or "No previous tree to compare against, a sane comparison is not possible.". And sometimes because etcupdate cannot automatically update many files in /etc/rc.d and manual merging of a lot of files with " " is realy painful while with mergemaster only simple keyboard shortcuts will solve it. All of this must be very stressful for beginners. So beside the update of documentation I really would like to see some changes to etcupdate workflow where files are modified in temporary location and moved to destination only if they do not contain any syntax breaking changes like , , . Kind regards Miroslav Lachman Agree. I fell back to mergemaster this Nov on 13-stable when the /var files pertaining to etcupdate were all missing current /etc data, and no study of man etcupdate was clear enough to rectify such a scenario, and suspect my initial use of etcupdate will or may require a planned reinstall, not having had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and I am just hoping mergemaster stays in /usr/src and updated for system changes, even if moved to 'tools' or something, since its use seems intuitive and much less of a black box. Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still. Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run) option of etcupdate is now quite harmful. Maybe by any commit done in this april on main (MFC'ed to stable/13 in june). *I got busy manually checking and applying changes to /etc, and forgot to file PR. Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does NOT do anything, hence nothing is actually updated. The only workaround I have is NOT to try dry-run. Humm. It would be because the same trees are used for dry-run and actual run. (Not looked into the code. Just a thought.) So the new changes always build a temporary tree (vs trying to build /var/db/etupdate/current in place). For -n it should be that it just doesn't change /var/db/etcupdate/current at the end, but if it did the move anyway that would explain the bug you are seeing. That does indeed look broken. Please file a PR as a reminder for me to fix it. -- John Baldwin
Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook
On 12/3/21 4:58 AM, Miroslav Lachman wrote: So beside the update of documentation I really would like to see some changes to etcupdate workflow where files are modified in temporary location and moved to destination only if they do not contain any syntax breaking changes like , , . This is what etcupdate does, so I'm a bit confused why you are getting merge markers in /etc. When an automated 3-way merge doesn't work due to conflicts, the file with the conflicts is saved in /var/db/etcupdate/conflicts/. It is only copied to /etc when you mark it as fully resolved when running 'etcupdate resolve'. Perhaps you had multiple conflicts in a modified file and when editing the file you only fixed the first one and then marked it as resolved at the prompt? Even in that case etcupdate explicitly prompts you a second time after you say "r" with "File still has conflicts, are you sure?", so it will only install a file to /etc with those changes if you have explicitly confirmed you want it. -- John Baldwin
Re: CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress
On Wed, Dec 08, 2021 at 04:05:16PM +0100, FreeBSD User wrote: > Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-CURRENT > #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fails with > the > linker error shown below. > > Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build. > > > [...] > cc -O2 -pipe -O3 -fno-common > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc > -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DNDEBUG > -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls > -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations > -Wthread-safety -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable > -Wno-error=unused-but-set-variable -Qunused-arguments > -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include > -static > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib > -o nm nm.o > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf > -ldwarf > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > -lelf > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc > -lelftc_pie > -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf > -lelf -legacy ld: error: undefined symbol: uncompress > >>> referenced by libdwarf_elf_init.c > >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive > >>> /usr/lib/libdwarf.a > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [nm] Error code 1 Is this build using WITHOUT_CLEAN? If so I think you'll need to try a clean build if you had previous built world between dbf05458e3bd and 8d5d329553b3.
CURRENT: can not build 13-STABLE: ld: error: undefined symbol: uncompress
Building recent 13-STABLE sources on a recent 14-CURRENT (FreeBSD 14.0-CURRENT #7 main-n251463-935dc0de881: Wed Dec 8 06:49:25 CET 2021 amd64) fails with the linker error shown below. Due to this error, no FreeBSD pkg base nor NanoBSD Image can be build. [...] cc -O2 -pipe -O3 -fno-common -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/libelftc -I/pool/poudriere/jails/13amd64/usr/src/contrib/elftoolchain/common -DNDEBUG -std=gnu99 -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Qunused-arguments -I/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/include -static -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/legacy/usr/lib -o nm nm.o -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libdwarf -ldwarf -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelftc -lelftc_pie -L/pool/sources/13-STABLE/obj//pool/poudriere/jails/13amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/libelf -lelf -legacy ld: error: undefined symbol: uncompress >>> referenced by libdwarf_elf_init.c >>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive >>> /usr/lib/libdwarf.a cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [nm] Error code 1
