thinstation-general — General List for Thinstation

[Thinstation-general] redirect / use usb camera

[aydin p. <pay...@gm...>]

Hello,

Using thinstation 6.2 I have managed to create an image which is used to
RDP to a Windows Server using smart card auth.
Client boots from PXE which is DELL WYSE-5070 thin client.
Working fine without any problems.

Is it possible to use a camera which is attached to a USB port on WYSE
5070?
I think it should be something like sound redirection if it is possible.

Regards,

Aydin

Re: [Thinstation-general] USB printer and CUPS

[Don C. <don...@ya...>]

That's some good information. I'm sure the community will appreciate it. You could even make a wiki page out of it, that can be worked over time.






On Friday, September 30, 2022 at 03:51:04 PM PDT, Doug Fraser via Thinstation-general <thi...@li...> wrote: 





I installed a .deb package on a linux system so it would recognize my printer.  I guess that my printer is a bit "non standard".   Since that worked, I thought I would do the same on thinstation.  When I did this, all I knew about cups was how to spell it.  I had made up several simple packages previously.  Here are a few things I hope to remember when I do this again.

I made up a package on thinstation and included it in the build.conf.   I didn't need to compile anything because I used a .deb package as a starting point.

I researched which button exactly  I need to press on the printer to cancel a print job.

I looked at the thinstation wiki entry for printing (need ghostscript) and at the thinstation.conf.sample in the /thinstation/build directory.

My .deb package wanted to put things in /usr/share but I put the /usr/share things in /lib and it worked (thanks to Don for getting me past this).

After defining my package, I defined the printer in the thinstation.conf.buildtime file.
Start the CUPS_PRINTER_0_NAME etc fields at 0.
I removed spaces from my CUPS_PRINT_0_NAME entry.  The sample has spaces but mine worked much better without them. 

I needed to be root to run these commands and did a su root using the password I changed in the build.conf.

lpinfo -v gives the CUPS_PRINTER_0_DEVICEURI and it starts with and includes the usb:// up until the first space
Note that lpinfo ? gives some info on parameters.

lpinfo -m | grep somestring gives the CUPS_PRINTER_0_DRIVER and it starts with drv:// and ends in with the first space.  I used part of the printer manufacturer's name as somestring to lessen the number of lines of output.  I picked out the file for my model of printer. 

To test this, I booted my build (if using a virtual machine, attach the printer to it), opened a file in leafpad, and selected file, print.  My printer name showed up as an option (maybe not the first time but eventually).

My alpha testing consisted of printing one file with one text line.  My beta tester has printed one pdf file with several pages.

I didn't get things right my first try.  I used the lpadmin command to debug.  You need to be root to run this command.  It complained that what I was using was deprecated but that complaint can be ignored.  Other complaints had to be addressed.

lpadmin -p printername -v printeruri -m printerdriver -E
Note that lpadmin ? gives some info on parameters.
Note Note that the -E has to be be after the -p.  The end is a good place.

Make sure that the printername, printeruri, and printerdriver are exactly as you have them in thinstation.conf.buildtime.




_______________________________________________
Thinstation-general mailing list
Thi...@li...
https://lists.sourceforge.net/lists/listinfo/thinstation-general

[Thinstation-general] USB printer and CUPS

[Doug F. <fra...@ya...>]

I installed a .deb package on a linux system so it would recognize my printer.  I guess that my printer is a bit "non standard".   Since that worked, I thought I would do the same on thinstation.  When I did this, all I knew about cups was how to spell it.  I had made up several simple packages previously.  Here are a few things I hope to remember when I do this again.
I made up a package on thinstation and included it in the build.conf.   I didn't need to compile anything because I used a .deb package as a starting point.

I researched which button exactly  I need to press on the printer to cancel a print job.

I looked at the thinstation wiki entry for printing (need ghostscript) and at the thinstation.conf.sample in the /thinstation/build directory.
My .deb package wanted to put things in /usr/share but I put the /usr/share things in /lib and it worked (thanks to Don for getting me past this).

After defining my package, I defined the printer in the thinstation.conf.buildtime file.
Start the CUPS_PRINTER_0_NAME etc fields at 0.I removed spaces from my CUPS_PRINT_0_NAME entry.  The sample has spaces but mine worked much better without them. 

I needed to be root to run these commands and did a su root using the password I changed in the build.conf.
lpinfo -v gives the CUPS_PRINTER_0_DEVICEURI and it starts with and includes the usb:// up until the first spaceNote that lpinfo ? gives some info on parameters.
lpinfo -m | grep somestring gives the CUPS_PRINTER_0_DRIVER and it starts with drv:// and ends in with the first space.  I used part of the printer manufacturer's name as somestring to lessen the number of lines of output.  I picked out the file for my model of printer. 

To test this, I booted my build (if using a virtual machine, attach the printer to it), opened a file in leafpad, and selected file, print.  My printer name showed up as an option (maybe not the first time but eventually).

My alpha testing consisted of printing one file with one text line.  My beta tester has printed one pdf file with several pages.

I didn't get things right my first try.  I used the lpadmin command to debug.  You need to be root to run this command.  It complained that what I was using was deprecated but that complaint can be ignored.  Other complaints had to be addressed.

lpadmin -p printername -v printeruri -m printerdriver -ENote that lpadmin ? gives some info on parameters.Note Note that the -E has to be be after the -p.  The end is a good place.

Make sure that the printername, printeruri, and printerdriver are exactly as you have them in thinstation.conf.buildtime.

Re: [Thinstation-general] problem with new package

[Doug F. <fra...@ya...>]

 That worked thanks.

    On Sunday, September 25, 2022, 12:10:07 a.m. UTC, Don Cupp via Thinstation-general <thi...@li...> wrote:  
 
 We don't use /usr. It's just a bunch a links that redirect back to root. Things that would normally go in /usr/share can just go into /lib






On Saturday, September 24, 2022 at 02:41:30 PM PDT, Doug Fraser via Thinstation-general <thi...@li...> wrote: 





I have an older package that works.  The directory structure follows:

my-blacklist-ata:
total 28
drwxr-xr-x    3 root     root          4096 Sep 23 10:28 .
drwxr-xr-x  429 root     root         16384 Sep 24 09:25 ..
-rw-r--r--    1 root     root             5 Sep 23 10:28 dependencies
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 etc

my-blacklist-ata/etc:
total 12
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 .
drwxr-xr-x    3 root     root          4096 Sep 23 10:28 ..
drwxr-xr-x    2 root     root          4096 Sep 23 05:30 modprobe.d

my-blacklist-ata/etc/modprobe.d:
total 12
drwxr-xr-x    2 root     root          4096 Sep 23 05:30 .
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 ..
-rw-r--r--    1 root     root           115 Apr 22  2021 ata-blacklist.conf

The file ata-blacklist.conf ends up in the directory etc/modprobe.d in the tmp-tree directory and in the /etc/modprobe.d directory in the thinstation image.  This is as I expected.

I have a new package.
my-brlaser:
total 28
drwxr-xr-x    3 root     root          4096 Sep 24 10:26 .
drwxr-xr-x  430 root     root         16384 Sep 24 12:53 ..
-rw-r--r--    1 root     root            22 Sep 24 09:32 dependencies
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 usr

my-brlaser/usr:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 .
drwxr-xr-x    3 root     root          4096 Sep 24 10:26 ..
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 share

my-brlaser/usr/share:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 .
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 ..
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 cups

my-brlaser/usr/share/cups:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 .
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 ..
drwxr-xr-x    2 root     root          4096 Sep 24 12:59 drv

my-brlaser/usr/share/cups/drv:
total 20
drwxr-xr-x    2 root     root          4096 Sep 24 12:59 .
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 ..
-rw-r--r--    1 root     root          9652 Mar 21  2020 brlaser.drv

The file brlaser.drv does not show up in the usr/share/cups/drv directory in the tmp-tree directory.  The directory listing for the tmp-tree follows:
tmp-tree/usr/share/cups/drv/:
total 252
drwxr-xr-x    3 root     root            66 Dec 31  2021 .
drwxr-xr-x   23 root     root           367 Dec 31  2021 ..
-rw-r--r--    1 root     root        214101 Dec 31  2021 cupsfilters.drv
drwxr-xr-x    2 root     root            33 Dec 31  2021 hp
-rw-r--r--    1 root     root         40790 Dec 31  2021 sample.drv

What have I done wrong?

thanks

_______________________________________________
Thinstation-general mailing list
Thi...@li...
https://lists.sourceforge.net/lists/listinfo/thinstation-general


_______________________________________________
Thinstation-general mailing list
Thi...@li...
https://lists.sourceforge.net/lists/listinfo/thinstation-general
  

Re: [Thinstation-general] problem with new package

[Don C. <don...@ya...>]

We don't use /usr. It's just a bunch a links that redirect back to root. Things that would normally go in /usr/share can just go into /lib






On Saturday, September 24, 2022 at 02:41:30 PM PDT, Doug Fraser via Thinstation-general <thi...@li...> wrote: 





I have an older package that works.  The directory structure follows:

my-blacklist-ata:
total 28
drwxr-xr-x    3 root     root          4096 Sep 23 10:28 .
drwxr-xr-x  429 root     root         16384 Sep 24 09:25 ..
-rw-r--r--    1 root     root             5 Sep 23 10:28 dependencies
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 etc

my-blacklist-ata/etc:
total 12
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 .
drwxr-xr-x    3 root     root          4096 Sep 23 10:28 ..
drwxr-xr-x    2 root     root          4096 Sep 23 05:30 modprobe.d

my-blacklist-ata/etc/modprobe.d:
total 12
drwxr-xr-x    2 root     root          4096 Sep 23 05:30 .
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 ..
-rw-r--r--    1 root     root           115 Apr 22  2021 ata-blacklist.conf

The file ata-blacklist.conf ends up in the directory etc/modprobe.d in the tmp-tree directory and in the /etc/modprobe.d directory in the thinstation image.  This is as I expected.

I have a new package.
my-brlaser:
total 28
drwxr-xr-x    3 root     root          4096 Sep 24 10:26 .
drwxr-xr-x  430 root     root         16384 Sep 24 12:53 ..
-rw-r--r--    1 root     root            22 Sep 24 09:32 dependencies
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 usr

my-brlaser/usr:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 .
drwxr-xr-x    3 root     root          4096 Sep 24 10:26 ..
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 share

my-brlaser/usr/share:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 .
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 ..
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 cups

my-brlaser/usr/share/cups:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 .
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 ..
drwxr-xr-x    2 root     root          4096 Sep 24 12:59 drv

my-brlaser/usr/share/cups/drv:
total 20
drwxr-xr-x    2 root     root          4096 Sep 24 12:59 .
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 ..
-rw-r--r--    1 root     root          9652 Mar 21  2020 brlaser.drv

The file brlaser.drv does not show up in the usr/share/cups/drv directory in the tmp-tree directory.  The directory listing for the tmp-tree follows:
tmp-tree/usr/share/cups/drv/:
total 252
drwxr-xr-x    3 root     root            66 Dec 31  2021 .
drwxr-xr-x   23 root     root           367 Dec 31  2021 ..
-rw-r--r--    1 root     root        214101 Dec 31  2021 cupsfilters.drv
drwxr-xr-x    2 root     root            33 Dec 31  2021 hp
-rw-r--r--    1 root     root         40790 Dec 31  2021 sample.drv

What have I done wrong?

thanks

_______________________________________________
Thinstation-general mailing list
Thi...@li...
https://lists.sourceforge.net/lists/listinfo/thinstation-general

[Thinstation-general] problem with new package

[Doug F. <fra...@ya...>]

I have an older package that works.  The directory structure follows:
my-blacklist-ata:
total 28
drwxr-xr-x    3 root     root          4096 Sep 23 10:28 .
drwxr-xr-x  429 root     root         16384 Sep 24 09:25 ..
-rw-r--r--    1 root     root             5 Sep 23 10:28 dependencies
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 etc

my-blacklist-ata/etc:
total 12
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 .
drwxr-xr-x    3 root     root          4096 Sep 23 10:28 ..
drwxr-xr-x    2 root     root          4096 Sep 23 05:30 modprobe.d

my-blacklist-ata/etc/modprobe.d:
total 12
drwxr-xr-x    2 root     root          4096 Sep 23 05:30 .
drwxr-xr-x    3 root     root          4096 Sep 23 05:30 ..
-rw-r--r--    1 root     root           115 Apr 22  2021 ata-blacklist.conf

The file ata-blacklist.conf ends up in the directory etc/modprobe.d in the tmp-tree directory and in the /etc/modprobe.d directory in the thinstation image.  This is as I expected.

I have a new package.my-brlaser:
total 28
drwxr-xr-x    3 root     root          4096 Sep 24 10:26 .
drwxr-xr-x  430 root     root         16384 Sep 24 12:53 ..
-rw-r--r--    1 root     root            22 Sep 24 09:32 dependencies
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 usr

my-brlaser/usr:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 .
drwxr-xr-x    3 root     root          4096 Sep 24 10:26 ..
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 share

my-brlaser/usr/share:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 .
drwxr-xr-x    3 root     root          4096 Sep 24 12:53 ..
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 cups

my-brlaser/usr/share/cups:
total 12
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 .
drwxr-xr-x    3 root     root          4096 Sep 24 09:26 ..
drwxr-xr-x    2 root     root          4096 Sep 24 12:59 drv

my-brlaser/usr/share/cups/drv:
total 20
drwxr-xr-x    2 root     root          4096 Sep 24 12:59 .
drwxr-xr-x    3 root     root          4096 Sep 24 12:59 ..
-rw-r--r--    1 root     root          9652 Mar 21  2020 brlaser.drv

The file brlaser.drv does not show up in the usr/share/cups/drv directory in the tmp-tree directory.  The directory listing for the tmp-tree follows:tmp-tree/usr/share/cups/drv/:
total 252
drwxr-xr-x    3 root     root            66 Dec 31  2021 .
drwxr-xr-x   23 root     root           367 Dec 31  2021 ..
-rw-r--r--    1 root     root        214101 Dec 31  2021 cupsfilters.drv
drwxr-xr-x    2 root     root            33 Dec 31  2021 hp
-rw-r--r--    1 root     root         40790 Dec 31  2021 sample.drv

What have I done wrong?
thanks

Re: [Thinstation-general] fyi firefox extensions location change

[Doug F. <fra...@ya...>]

 I have opened an issue on github.

    On Wednesday, September 21, 2022, 09:36:46 p.m. UTC, Don Cupp via Thinstation-general <thi...@li...> wrote:  
 
 
Can you send a PR?





On Wednesday, September 21, 2022 at 01:58:11 PM PDT, Doug Fraser via Thinstation-general <thi...@li...> wrote: 





The firefox extensions have moved.  The noscript extension was not found.  I changed the buildurls file as follows.

param noscripturl    https://addons.mozilla.org/firefox/downloads/file/3996751/noscript-11.4.10.xpi
#param noscripturl    https://addons.cdn.mozilla.net/user-media/addons/722/noscript_security_suite-11.1.5-an+fx.xpi


Here are the links for the other two extensions in the buildurls file.

https://addons.mozilla.org/firefox/downloads/file/3809748/https_everywhere-2021.7.13.xpi

https://addons.mozilla.org/firefox/downloads/file/3952467/user_agent_string_switcher-0.4.8.xpi
_______________________________________________
Thinstation-general mailing list
Thi...@li...
https://lists.sourceforge.net/lists/listinfo/thinstation-general


_______________________________________________
Thinstation-general mailing list
Thi...@li...
https://lists.sourceforge.net/lists/listinfo/thinstation-general
  

Re: [Thinstation-general] fyi firefox extensions location change

[Don C. <don...@ya...>]

Can you send a PR?





On Wednesday, September 21, 2022 at 01:58:11 PM PDT, Doug Fraser via Thinstation-general <thi...@li...> wrote: 





The firefox extensions have moved.  The noscript extension was not found.  I changed the buildurls file as follows.

param noscripturl    https://addons.mozilla.org/firefox/downloads/file/3996751/noscript-11.4.10.xpi
#param noscripturl    https://addons.cdn.mozilla.net/user-media/addons/722/noscript_security_suite-11.1.5-an+fx.xpi


Here are the links for the other two extensions in the buildurls file.

https://addons.mozilla.org/firefox/downloads/file/3809748/https_everywhere-2021.7.13.xpi

https://addons.mozilla.org/firefox/downloads/file/3952467/user_agent_string_switcher-0.4.8.xpi
_______________________________________________
Thinstation-general mailing list
Thi...@li...
https://lists.sourceforge.net/lists/listinfo/thinstation-general

[Thinstation-general] fyi firefox extensions location change

[Doug F. <fra...@ya...>]

The firefox extensions have moved.  The noscript extension was not found.  I changed the buildurls file as follows.
param noscripturl    https://addons.mozilla.org/firefox/downloads/file/3996751/noscript-11.4.10.xpi
#param noscripturl    https://addons.cdn.mozilla.net/user-media/addons/722/noscript_security_suite-11.1.5-an+fx.xpi


Here are the links for the other two extensions in the buildurls file.

https://addons.mozilla.org/firefox/downloads/file/3809748/https_everywhere-2021.7.13.xpi
https://addons.mozilla.org/firefox/downloads/file/3952467/user_agent_string_switcher-0.4.8.xpi

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

Autonet.  Have never tried network manager yet.


On May 4, 2022 6:10:38 p.m. Don Cupp <don...@ya...> wrote:
> Ok.
>
> Networkmanager or autonet?
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Wednesday, May 4, 2022, 2:53 PM, Todd Pfaff <pf...@rh...> wrote:
> Sorry, what do you mean by "with network stacks?"?
>
> I'll check the net device and get back to you, but given that it works when 
> pxe booting, it's unlikely a firmware or driver issue (except maybe the 
> driver isn't loaded ... But why?)
>
>
> On May 4, 2022 5:39:42 p.m. Don Cupp <don...@ya...> wrote:
>> With network stacks?
>>
>> What kind of network adapter?
>> Possibly a firmware issue.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff 
>> <pf...@rh...> wrote:
>> Sorry, I just realized that I'd been using the wrong thread for this
>> subject matter today.
>>
>> I've changed my NET_ entries in build to conf to NET_IPV4 equivalents
>> based on what I could find in various files under build/.  This is what I
>> now have in thinstation.conf.buildtime:
>>
>> NET_USE=LAN
>> NET_USE_DHCP=off
>> NET_HOSTNAME=tc1
>> NET_IPV4_MODE=manual
>> NET_IPV4_ADDRESS=192.168.1.2/24
>> NET_IPV4_GATEWAY=192.168.1.1
>> NET_IPV4_DNS1=8.8.8.8
>> NET_IPV4_DNS_SEARCH=mydomain.com
>>
>>
>> I then did a new build and then wrote my usb drive with:
>>
>> mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>> /build/boot-images/grub/efi-source \
>> /dev/sdh
>>
>>
>> Boot fails in the same way as before, with the network unconfigured.
>>
>> I tried again but with fastboot=false.
>>
>> Same thing.  No network configuration.
>>
>> I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
>> That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg
>> to look like this:
>>
>> menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu
>> --class os --unrestricted {
>> set enable_progress_indicator=1
>> linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM
>> NET_IPV4_MODE=manual
>> NET_IPV4_ADDRESS=192.168.1.2/24
>> NET_IPV4_GATEWAY=192.168.1.1
>> NET_IPV4_DNS="1.1.1.1;2.2.2.2"
>> NET_IPV4_DNS_SEARCH="mydomain.com"
>> initrd /boot/initrd
>> }
>>
>>
>> All those NET_ entries follow the LM=$LM on the same line, it's just split
>> in this email.
>>
>> Booted again, kernel loads, initrd loads, and sometime later it fails
>> in the same way, with no network configuration.
>>
>> What could I possible be doing wrong now?
>>
>>
>> Btw, what does this syntax mean?
>>
>> NET_HOSTNAME=tc_*
>>
>>
>> Thanks,
>> Todd
>>
>>
>>
>> On Wed, 4 May 2022, Don Cupp wrote:
>>
>>> Yep, your getting used to my organization already :)
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
>>> wrote:
>>>
>>>      I assume I should look here for details, yes?
>>>
>>>      [root@TS_chroot]/build# less
>>>      packages/autonet/etc/udev/scripts/net.sh
>>>
>>>
>>>      or, if I were using the networkmanager package, look hereabouts?
>>>
>>>      ./packages/networkmanager/build/conf/64networkmanager
>>>
>>>
>>>
>>>      On Wed, 4 May 2022, Todd Pfaff wrote:
>>>
>>>      > omg.  I wish I'd asked earlier.  So sad for time wasted.
>>>      >
>>>      > I find plenty of old references to NET_(!IPV4)_stuff that I
>>>      was following. I
>>>      > have not yet come across a single googlematch that lead me in
>>>      the
>>>      > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>>>      under build/, I
>>>      > see.
>>>      >
>>>      > Anyway, thanks, better late than never. :)
>>>      >
>>>      >
>>>      > On Wed, 4 May 2022, Don Cupp wrote:
>>>      >
>>>      >>  I think it changed to NET_IPV4 prefix a few years back.
>>>      Where did you get
>>>      >>  that code? I’ll update it.
>>>      >>
>>>      >>  Sent from Yahoo Mail for iPhone
>>>      >>
>>>      >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>>>      <pf...@rh...>
>>>      >>  wrote:
>>>      >>
>>>      >>        I first tried this (my usb drive is sdh):
>>>      >>
>>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>>      >>        /build/boot-images/systemd-boot-iso/efi-source
>>>      /dev/sdh
>>>      >>
>>>      >>
>>>      >>        I then plugged that usb drive to my thinstation
>>>      machine and
>>>      >>        booted.  I had
>>>      >>        to add the uefi boot entry manually - it wasn't
>>>      autodetected -
>>>      >>        not sure if
>>>      >>        that is "normal".  Booting started but failed, I
>>>      think, because
>>>      >>        my network
>>>      >>        wasn't configured.  I'm aiming for a static network
>>>      >>        configuration in this
>>>      >>        case.
>>>      >>
>>>      >>        I next tried with refind:
>>>      >>
>>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>>      >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>>>      >>
>>>      >>
>>>      >>        Same dance, same failure mode - no network
>>>      configuration.
>>>      >>
>>>      >>
>>>      >>        I have this in my thinstation.conf.buildtime:
>>>      >>
>>>      >>        NET_HOSTNAME=tc003
>>>      >>        NET_IP_ADDRESS=192.168.1.2
>>>      >>        NET_GATEWAY=192.168.1.1
>>>      >>        NET_USE=LAN
>>>      >>        NET_USE_DHCP=false
>>>      >>        NET_MASK=255.255.255.0
>>>      >>        NET_DNS_SEARCH="mydomain.com"
>>>      >>        NET_DNS1=8.8.8.8
>>>      >>
>>>      >>
>>>      >>        What am I missing?  Is there anything else I need to
>>>      add to
>>>      >>        either
>>>      >>        build.conf or thinstation.conf.buildtime to be able to
>>>      efi boot
>>>      >>        from a usb
>>>      >>        drive with a static network configuration?
>>>      >>
>>>      >>        Thanks,
>>>      >>        Todd
>>>      >>
>>>      >>
>>>      >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>>>      >>
>>>      >>      >  This is all very interesting.  I looked at bt, and
>>>      flash, and
>>>      >>        mkgptdrv. Lots
>>>      >>      >  of archaeological excavation to do.
>>>      >>      >
>>>      >>      >  What is the current recommended way to write a UEFI
>>>      bootable
>>>      >>        USB drive from a
>>>      >>      >  command line in the chroot environment?  I don't want
>>>      to
>>>      >>        bother with
>>>      >>      >  Windows+rufus is I can possibly avoid that.
>>>      >>      >
>>>      >>      >  My guess is that I could either use your
>>>      /ts/bin/flash script,
>>>      >>        or I could use
>>>      >>      >  a command line similar to what I see in flash, using
>>>      mkgptdrv
>>>      >>        or mkmbrdrv.
>>>      >>      >  Correct?
>>>      >>      >
>>>      >>      >  In this particular case, since I need to UEFI boot, I
>>>      think I
>>>      >>        need mkgptdrv
>>>      >>      >  rather than mkmbrdrv.  Correct?
>>>      >>      >
>>>      >>      >  So, looking at your flash script, you have this entry
>>>      that
>>>      >>        uses mkgptdrv:
>>>      >>      >
>>>      >>      > systemd)
>>>      >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>>>      >>      >  /build/boot-images/systemd-boot-iso/efi-source
>>>      /dev/sdb
>>>      >>      >
>>>      >>      >
>>>      >>      >  which leads me to believe that I'll need
>>>      >>        boot-images/systemd-boot-iso, and
>>>      >>      >  based on what I see in the build script, this means
>>>      that I
>>>      >>        have to add
>>>      >>      >  systemd-boot-iso to param bootimages in build.conf.
>>>      Correct?
>>>      >>      >
>>>      >>      >  In general, do you recommend just leaving param
>>>      bootimages
>>>      >>        empty so that the
>>>      >>      >  build script sets it to it's default as it does with
>>>      this
>>>      >>        code?
>>>      >>      >
>>>      >>      > if [ -z "$ts_bootimages" ]; then
>>>      >>      >         ts_bootimages="syslinux iso pxe refind-iso
>>>      >>        systemd-boot-iso grub"
>>>      >>      >
>>>      >>      >
>>>      >>      >  Is "systemd-boot-iso" the best option to use for my
>>>      use case
>>>      >>        of a UEFI
>>>      >>      >  bootable USB drive, or is there something else I
>>>      should
>>>      >>        consider that's
>>>      >>      >  already baked into the TS6.2 pie (and hopefully won't
>>>      require
>>>      >>        me to make too
>>>      >>      >  many more educated guesses :).
>>>      >>      >
>>>      >>      >  Thanks,
>>>      >>      >  Todd
>>>      >>      >
>>>      >>      >
>>>      >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>>>      >>      >
>>>      >>      >>   You can also open the file /ts/bin/bt in a text
>>>      editor and
>>>      >>        look at the
>>>      >>      >>   code I use for doing different things.
>>>      >>      >>
>>>      >>      >>   Have a look at
>>>      >>      >>
>>>      >>      >>   wrap_grub_efi() for some clues.
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>>>      >>        <don...@ya...>
>>>      >>      >>   wrote:
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   After doing a build, try
>>>      >>      >>   bt net or bt net-efi
>>>      >>      >>   to test a pxe boot and possibly an install
>>>      >>      >>   afterwards,
>>>      >>      >>   bt image-grub to test your install
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>>>      via
>>>      >>        Thinstation-general
>>>      >>      >>   <thi...@li...> wrote:
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   I use fedora. It’s not the code, just how the
>>>      distro is
>>>      >>        handling umount.
>>>      >>      >>   You can see me calling it. On Ubuntu, if I don’t
>>>      use lazy
>>>      >>        umount, it hangs
>>>      >>      >>   the exit.
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   Sent from Yahoo Mail for iPhone
>>>      >>      >>
>>>      >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>>>      >>        <pf...@rh...>
>>>      >>      >>   wrote:
>>>      >>      >>>   It's trivial.  I just run the following command
>>>      several
>>>      >>        times after I
>>>      >>      >>>   exit
>>>      >>      >>>   the setup-chroot shell.  It has become as quick as
>>>      a !for
>>>      >>        in my build
>>>      >>      >>>   shell.
>>>      >>      >>>
>>>      >>      >>>   for f in `mount|grep thinstation | awk '{print
>>>      $3}'`; do
>>>      >>        echo $f; umount
>>>      >>      >>>   $f; done
>>>      >>      >>>
>>>      >>      >>>
>>>      >>      >>>   So, no big deal, just unexpected.
>>>      >>      >>>
>>>      >>      >>>   If we're blaming this on the distro, that really
>>>      suprises
>>>      >>        me since you're
>>>      >>      >>>   basically saying that there are either very few
>>>      ThinStation
>>>      >>        users who are
>>>      >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>>>      other TS
>>>      >>        users who do
>>>      >>      >>>   use
>>>      >>      >>>   the same distro as me are just suffering in
>>>      silence.
>>>      >>        Maybe, who knows.
>>>      >>      >>>   I'd also find it hard to believe this is distro
>>>      related
>>>      >>        given that
>>>      >>      >>>   setup-chroot is just bash code, and not terribly
>>>      complex
>>>      >>        bash code at
>>>      >>      >>>   that.  I'm curious now though: on what distro(s)
>>>      does this
>>>      >>        all work
>>>      >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>>>      to ease
>>>      >>        my pain.
>>>      >>      >>>
>>>      >>      >>>   Todd
>>>      >>      >>>
>>>      >>      >>>
>>>      >>      >>>   On Mon, 2 May 2022, Don Cupp via
>>>      Thinstation-general wrote:
>>>      >>      >>>
>>>      >>      >>>>   Oh the sadness of the various distro
>>>      peculiarities. How
>>>      >>        long does it
>>>      >>      >>>>   take to try and unmount everything?
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>>>      Pfaff
>>>      >>      >>>>   <pf...@rh...> wrote:
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>>>      2022-04-01.
>>>      >>      >>>>
>>>      >>      >>>>   I'm doing builds on a CentOS 7 host.
>>>      >>      >>>>
>>>      >>      >>>>   Something with setup-chroot is faulty.  When I
>>>      exit from
>>>      >>        setup-chroot,
>>>      >>      >>>>   it
>>>      >>      >>>>   does not unmount things like it's supposed to.  I
>>>      can
>>>      >>        clearly see the
>>>      >>      >>>>   code
>>>      >>      >>>>   in setup-chroot in function do_unmounts() that is
>>>      supposed
>>>      >>        to do
>>>      >>      >>>>   the unmount, and I can see from where this is
>>>      called, but
>>>      >>        it's not doing
>>>      >>      >>>>   its job.
>>>      >>      >>>>
>>>      >>      >>>>   This is then somehow leading to various
>>>      problems.  We've
>>>      >>        seen both /dev/
>>>      >>      >>>>   and /dev/pts/ go empty while I've been working
>>>      with ts6.2
>>>      >>        recently.
>>>      >>      >>>>
>>>      >>      >>>>   Todd
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   _______________________________________________
>>>      >>      >>>>   Thinstation-general mailing list
>>>      >>      >>>>   Thi...@li...
>>>      >>      >>>>
>>>      >>
>>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>      >>      >>
>>>      >>      >>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   _______________________________________________
>>>      >>      >>>>   Thinstation-general mailing list
>>>      >>      >>>>   Thi...@li...
>>>      >>      >>>>
>>>      >>
>>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>      >>      >>>>
>>>      >>      >>
>>>      >>      >>   _______________________________________________
>>>      >>      >>   Thinstation-general mailing list
>>>      >>      >>   Thi...@li...
>>>      >>      >>
>>>      >>
>>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>      >>      >>
>>>      >>      >>
>>>      >>      >
>>>      >>      >
>>>      >>
>>>      >>
>>>      >>
>>>      >
>>>      >
>>>
>>>
>>>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

Tried that already, as mentioned in a previous message today.

On May 4, 2022 6:09:37 p.m. Don Cupp <don...@ya...> wrote:
> So start without fastboot. It likely needs to know what volume name was 
> assigned to the usb drive.
>
>
>
> Sent from Yahoo Mail for iPhone
>
> On Wednesday, May 4, 2022, 2:50 PM, Todd Pfaff <pf...@rh...> wrote:
> I can pxe boot ts6.2 on this same system and it works great.
>
> Now I need to move it to a network location where I can't pxe boot it so 
> I'm trying to get it working with the usb boot drive.
>
>
>
> On May 4, 2022 5:39:42 p.m. Don Cupp <don...@ya...> wrote:
>> With network stacks?
>>
>> What kind of network adapter?
>> Possibly a firmware issue.
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>>
>> Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff 
>> <pf...@rh...> wrote:
>> Sorry, I just realized that I'd been using the wrong thread for this
>> subject matter today.
>>
>> I've changed my NET_ entries in build to conf to NET_IPV4 equivalents
>> based on what I could find in various files under build/.  This is what I
>> now have in thinstation.conf.buildtime:
>>
>> NET_USE=LAN
>> NET_USE_DHCP=off
>> NET_HOSTNAME=tc1
>> NET_IPV4_MODE=manual
>> NET_IPV4_ADDRESS=192.168.1.2/24
>> NET_IPV4_GATEWAY=192.168.1.1
>> NET_IPV4_DNS1=8.8.8.8
>> NET_IPV4_DNS_SEARCH=mydomain.com
>>
>>
>> I then did a new build and then wrote my usb drive with:
>>
>> mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>> /build/boot-images/grub/efi-source \
>> /dev/sdh
>>
>>
>> Boot fails in the same way as before, with the network unconfigured.
>>
>> I tried again but with fastboot=false.
>>
>> Same thing.  No network configuration.
>>
>> I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
>> That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg
>> to look like this:
>>
>> menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu
>> --class os --unrestricted {
>> set enable_progress_indicator=1
>> linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM
>> NET_IPV4_MODE=manual
>> NET_IPV4_ADDRESS=192.168.1.2/24
>> NET_IPV4_GATEWAY=192.168.1.1
>> NET_IPV4_DNS="1.1.1.1;2.2.2.2"
>> NET_IPV4_DNS_SEARCH="mydomain.com"
>> initrd /boot/initrd
>> }
>>
>>
>> All those NET_ entries follow the LM=$LM on the same line, it's just split
>> in this email.
>>
>> Booted again, kernel loads, initrd loads, and sometime later it fails
>> in the same way, with no network configuration.
>>
>> What could I possible be doing wrong now?
>>
>>
>> Btw, what does this syntax mean?
>>
>> NET_HOSTNAME=tc_*
>>
>>
>> Thanks,
>> Todd
>>
>>
>>
>> On Wed, 4 May 2022, Don Cupp wrote:
>>
>>> Yep, your getting used to my organization already :)
>>>
>>>
>>> Sent from Yahoo Mail for iPhone
>>>
>>> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
>>> wrote:
>>>
>>>      I assume I should look here for details, yes?
>>>
>>>      [root@TS_chroot]/build# less
>>>      packages/autonet/etc/udev/scripts/net.sh
>>>
>>>
>>>      or, if I were using the networkmanager package, look hereabouts?
>>>
>>>      ./packages/networkmanager/build/conf/64networkmanager
>>>
>>>
>>>
>>>      On Wed, 4 May 2022, Todd Pfaff wrote:
>>>
>>>      > omg.  I wish I'd asked earlier.  So sad for time wasted.
>>>      >
>>>      > I find plenty of old references to NET_(!IPV4)_stuff that I
>>>      was following. I
>>>      > have not yet come across a single googlematch that lead me in
>>>      the
>>>      > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>>>      under build/, I
>>>      > see.
>>>      >
>>>      > Anyway, thanks, better late than never. :)
>>>      >
>>>      >
>>>      > On Wed, 4 May 2022, Don Cupp wrote:
>>>      >
>>>      >>  I think it changed to NET_IPV4 prefix a few years back.
>>>      Where did you get
>>>      >>  that code? I’ll update it.
>>>      >>
>>>      >>  Sent from Yahoo Mail for iPhone
>>>      >>
>>>      >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>>>      <pf...@rh...>
>>>      >>  wrote:
>>>      >>
>>>      >>        I first tried this (my usb drive is sdh):
>>>      >>
>>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>>      >>        /build/boot-images/systemd-boot-iso/efi-source
>>>      /dev/sdh
>>>      >>
>>>      >>
>>>      >>        I then plugged that usb drive to my thinstation
>>>      machine and
>>>      >>        booted.  I had
>>>      >>        to add the uefi boot entry manually - it wasn't
>>>      autodetected -
>>>      >>        not sure if
>>>      >>        that is "normal".  Booting started but failed, I
>>>      think, because
>>>      >>        my network
>>>      >>        wasn't configured.  I'm aiming for a static network
>>>      >>        configuration in this
>>>      >>        case.
>>>      >>
>>>      >>        I next tried with refind:
>>>      >>
>>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>>      >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>>>      >>
>>>      >>
>>>      >>        Same dance, same failure mode - no network
>>>      configuration.
>>>      >>
>>>      >>
>>>      >>        I have this in my thinstation.conf.buildtime:
>>>      >>
>>>      >>        NET_HOSTNAME=tc003
>>>      >>        NET_IP_ADDRESS=192.168.1.2
>>>      >>        NET_GATEWAY=192.168.1.1
>>>      >>        NET_USE=LAN
>>>      >>        NET_USE_DHCP=false
>>>      >>        NET_MASK=255.255.255.0
>>>      >>        NET_DNS_SEARCH="mydomain.com"
>>>      >>        NET_DNS1=8.8.8.8
>>>      >>
>>>      >>
>>>      >>        What am I missing?  Is there anything else I need to
>>>      add to
>>>      >>        either
>>>      >>        build.conf or thinstation.conf.buildtime to be able to
>>>      efi boot
>>>      >>        from a usb
>>>      >>        drive with a static network configuration?
>>>      >>
>>>      >>        Thanks,
>>>      >>        Todd
>>>      >>
>>>      >>
>>>      >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>>>      >>
>>>      >>      >  This is all very interesting.  I looked at bt, and
>>>      flash, and
>>>      >>        mkgptdrv. Lots
>>>      >>      >  of archaeological excavation to do.
>>>      >>      >
>>>      >>      >  What is the current recommended way to write a UEFI
>>>      bootable
>>>      >>        USB drive from a
>>>      >>      >  command line in the chroot environment?  I don't want
>>>      to
>>>      >>        bother with
>>>      >>      >  Windows+rufus is I can possibly avoid that.
>>>      >>      >
>>>      >>      >  My guess is that I could either use your
>>>      /ts/bin/flash script,
>>>      >>        or I could use
>>>      >>      >  a command line similar to what I see in flash, using
>>>      mkgptdrv
>>>      >>        or mkmbrdrv.
>>>      >>      >  Correct?
>>>      >>      >
>>>      >>      >  In this particular case, since I need to UEFI boot, I
>>>      think I
>>>      >>        need mkgptdrv
>>>      >>      >  rather than mkmbrdrv.  Correct?
>>>      >>      >
>>>      >>      >  So, looking at your flash script, you have this entry
>>>      that
>>>      >>        uses mkgptdrv:
>>>      >>      >
>>>      >>      > systemd)
>>>      >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>>>      >>      >  /build/boot-images/systemd-boot-iso/efi-source
>>>      /dev/sdb
>>>      >>      >
>>>      >>      >
>>>      >>      >  which leads me to believe that I'll need
>>>      >>        boot-images/systemd-boot-iso, and
>>>      >>      >  based on what I see in the build script, this means
>>>      that I
>>>      >>        have to add
>>>      >>      >  systemd-boot-iso to param bootimages in build.conf.
>>>      Correct?
>>>      >>      >
>>>      >>      >  In general, do you recommend just leaving param
>>>      bootimages
>>>      >>        empty so that the
>>>      >>      >  build script sets it to it's default as it does with
>>>      this
>>>      >>        code?
>>>      >>      >
>>>      >>      > if [ -z "$ts_bootimages" ]; then
>>>      >>      >         ts_bootimages="syslinux iso pxe refind-iso
>>>      >>        systemd-boot-iso grub"
>>>      >>      >
>>>      >>      >
>>>      >>      >  Is "systemd-boot-iso" the best option to use for my
>>>      use case
>>>      >>        of a UEFI
>>>      >>      >  bootable USB drive, or is there something else I
>>>      should
>>>      >>        consider that's
>>>      >>      >  already baked into the TS6.2 pie (and hopefully won't
>>>      require
>>>      >>        me to make too
>>>      >>      >  many more educated guesses :).
>>>      >>      >
>>>      >>      >  Thanks,
>>>      >>      >  Todd
>>>      >>      >
>>>      >>      >
>>>      >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>>>      >>      >
>>>      >>      >>   You can also open the file /ts/bin/bt in a text
>>>      editor and
>>>      >>        look at the
>>>      >>      >>   code I use for doing different things.
>>>      >>      >>
>>>      >>      >>   Have a look at
>>>      >>      >>
>>>      >>      >>   wrap_grub_efi() for some clues.
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>>>      >>        <don...@ya...>
>>>      >>      >>   wrote:
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   After doing a build, try
>>>      >>      >>   bt net or bt net-efi
>>>      >>      >>   to test a pxe boot and possibly an install
>>>      >>      >>   afterwards,
>>>      >>      >>   bt image-grub to test your install
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>>>      via
>>>      >>        Thinstation-general
>>>      >>      >>   <thi...@li...> wrote:
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   I use fedora. It’s not the code, just how the
>>>      distro is
>>>      >>        handling umount.
>>>      >>      >>   You can see me calling it. On Ubuntu, if I don’t
>>>      use lazy
>>>      >>        umount, it hangs
>>>      >>      >>   the exit.
>>>      >>      >>
>>>      >>      >>
>>>      >>      >>   Sent from Yahoo Mail for iPhone
>>>      >>      >>
>>>      >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>>>      >>        <pf...@rh...>
>>>      >>      >>   wrote:
>>>      >>      >>>   It's trivial.  I just run the following command
>>>      several
>>>      >>        times after I
>>>      >>      >>>   exit
>>>      >>      >>>   the setup-chroot shell.  It has become as quick as
>>>      a !for
>>>      >>        in my build
>>>      >>      >>>   shell.
>>>      >>      >>>
>>>      >>      >>>   for f in `mount|grep thinstation | awk '{print
>>>      $3}'`; do
>>>      >>        echo $f; umount
>>>      >>      >>>   $f; done
>>>      >>      >>>
>>>      >>      >>>
>>>      >>      >>>   So, no big deal, just unexpected.
>>>      >>      >>>
>>>      >>      >>>   If we're blaming this on the distro, that really
>>>      suprises
>>>      >>        me since you're
>>>      >>      >>>   basically saying that there are either very few
>>>      ThinStation
>>>      >>        users who are
>>>      >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>>>      other TS
>>>      >>        users who do
>>>      >>      >>>   use
>>>      >>      >>>   the same distro as me are just suffering in
>>>      silence.
>>>      >>        Maybe, who knows.
>>>      >>      >>>   I'd also find it hard to believe this is distro
>>>      related
>>>      >>        given that
>>>      >>      >>>   setup-chroot is just bash code, and not terribly
>>>      complex
>>>      >>        bash code at
>>>      >>      >>>   that.  I'm curious now though: on what distro(s)
>>>      does this
>>>      >>        all work
>>>      >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>>>      to ease
>>>      >>        my pain.
>>>      >>      >>>
>>>      >>      >>>   Todd
>>>      >>      >>>
>>>      >>      >>>
>>>      >>      >>>   On Mon, 2 May 2022, Don Cupp via
>>>      Thinstation-general wrote:
>>>      >>      >>>
>>>      >>      >>>>   Oh the sadness of the various distro
>>>      peculiarities. How
>>>      >>        long does it
>>>      >>      >>>>   take to try and unmount everything?
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>>>      Pfaff
>>>      >>      >>>>   <pf...@rh...> wrote:
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>>>      2022-04-01.
>>>      >>      >>>>
>>>      >>      >>>>   I'm doing builds on a CentOS 7 host.
>>>      >>      >>>>
>>>      >>      >>>>   Something with setup-chroot is faulty.  When I
>>>      exit from
>>>      >>        setup-chroot,
>>>      >>      >>>>   it
>>>      >>      >>>>   does not unmount things like it's supposed to.  I
>>>      can
>>>      >>        clearly see the
>>>      >>      >>>>   code
>>>      >>      >>>>   in setup-chroot in function do_unmounts() that is
>>>      supposed
>>>      >>        to do
>>>      >>      >>>>   the unmount, and I can see from where this is
>>>      called, but
>>>      >>        it's not doing
>>>      >>      >>>>   its job.
>>>      >>      >>>>
>>>      >>      >>>>   This is then somehow leading to various
>>>      problems.  We've
>>>      >>        seen both /dev/
>>>      >>      >>>>   and /dev/pts/ go empty while I've been working
>>>      with ts6.2
>>>      >>        recently.
>>>      >>      >>>>
>>>      >>      >>>>   Todd
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   _______________________________________________
>>>      >>      >>>>   Thinstation-general mailing list
>>>      >>      >>>>   Thi...@li...
>>>      >>      >>>>
>>>      >>
>>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>      >>      >>
>>>      >>      >>>
>>>      >>      >>>>
>>>      >>      >>>>
>>>      >>      >>>>   _______________________________________________
>>>      >>      >>>>   Thinstation-general mailing list
>>>      >>      >>>>   Thi...@li...
>>>      >>      >>>>
>>>      >>
>>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>      >>      >>>>
>>>      >>      >>
>>>      >>      >>   _______________________________________________
>>>      >>      >>   Thinstation-general mailing list
>>>      >>      >>   Thi...@li...
>>>      >>      >>
>>>      >>
>>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>      >>      >>
>>>      >>      >>
>>>      >>      >
>>>      >>      >
>>>      >>
>>>      >>
>>>      >>
>>>      >
>>>      >
>>>
>>>
>>>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Don C. <don...@ya...>]

Ok.
Networkmanager or autonet?


Sent from Yahoo Mail for iPhone


On Wednesday, May 4, 2022, 2:53 PM, Todd Pfaff <pf...@rh...> wrote:

Sorry, what do you mean by "with network stacks?"?
I'll check the net device and get back to you, but given that it works when pxe booting, it's unlikely a firmware or driver issue (except maybe the driver isn't loaded ... But why?)


On May 4, 2022 5:39:42 p.m. Don Cupp <don...@ya...> wrote:

With network stacks?
What kind of network adapter?Possibly a firmware issue.


Sent from Yahoo Mail for iPhone


Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff <pf...@rh...> wrote:

Sorry, I just realized that I'd been using the wrong thread for this 
subject matter today.

I've changed my NET_ entries in build to conf to NET_IPV4 equivalents 
based on what I could find in various files under build/.  This is what I 
now have in thinstation.conf.buildtime:

NET_USE=LAN
NET_USE_DHCP=off
NET_HOSTNAME=tc1
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS1=8.8.8.8
NET_IPV4_DNS_SEARCH=mydomain.com


I then did a new build and then wrote my usb drive with:

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/grub/efi-source \
/dev/sdh


Boot fails in the same way as before, with the network unconfigured.

I tried again but with fastboot=false.

Same thing.  No network configuration.

I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg 
to look like this:

menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu 
--class os --unrestricted {
        set enable_progress_indicator=1
        linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM 
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24 
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS="1.1.1.1;2.2.2.2"
NET_IPV4_DNS_SEARCH="mydomain.com"
        initrd /boot/initrd
}


All those NET_ entries follow the LM=$LM on the same line, it's just split 
in this email.

Booted again, kernel loads, initrd loads, and sometime later it fails
in the same way, with no network configuration.

What could I possible be doing wrong now?


Btw, what does this syntax mean?

NET_HOSTNAME=tc_*


Thanks,
Todd


On Wed, 4 May 2022, Don Cupp wrote:

> Yep, your getting used to my organization already :)
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
> wrote:
>
>      I assume I should look here for details, yes?
>
>      [root@TS_chroot]/build# less
>      packages/autonet/etc/udev/scripts/net.sh
> 
>
>      or, if I were using the networkmanager package, look hereabouts?
>
>      ./packages/networkmanager/build/conf/64networkmanager
> 
> 
>
>      On Wed, 4 May 2022, Todd Pfaff wrote:
>
>      > omg.  I wish I'd asked earlier.  So sad for time wasted.
>      >
>      > I find plenty of old references to NET_(!IPV4)_stuff that I
>      was following. I
>      > have not yet come across a single googlematch that lead me in
>      the
>      > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>      under build/, I
>      > see.
>      >
>      > Anyway, thanks, better late than never. :)
>      >
>      >
>      > On Wed, 4 May 2022, Don Cupp wrote:
>      >
>      >>  I think it changed to NET_IPV4 prefix a few years back.
>      Where did you get
>      >>  that code? I’ll update it.
>      >>
>      >>  Sent from Yahoo Mail for iPhone
>      >>
>      >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>      <pf...@rh...>
>      >>  wrote:
>      >>
>      >>        I first tried this (my usb drive is sdh):
>      >>
>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>      >>        /build/boot-images/systemd-boot-iso/efi-source
>      /dev/sdh
>      >>
>      >>
>      >>        I then plugged that usb drive to my thinstation
>      machine and
>      >>        booted.  I had
>      >>        to add the uefi boot entry manually - it wasn't
>      autodetected -
>      >>        not sure if
>      >>        that is "normal".  Booting started but failed, I
>      think, because
>      >>        my network
>      >>        wasn't configured.  I'm aiming for a static network
>      >>        configuration in this
>      >>        case.
>      >>
>      >>        I next tried with refind:
>      >>
>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>      >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>      >>
>      >>
>      >>        Same dance, same failure mode - no network
>      configuration.
>      >>
>      >>
>      >>        I have this in my thinstation.conf.buildtime:
>      >>
>      >>        NET_HOSTNAME=tc003
>      >>        NET_IP_ADDRESS=192.168.1.2
>      >>        NET_GATEWAY=192.168.1.1
>      >>        NET_USE=LAN
>      >>        NET_USE_DHCP=false
>      >>        NET_MASK=255.255.255.0
>      >>        NET_DNS_SEARCH="mydomain.com"
>      >>        NET_DNS1=8.8.8.8
>      >>
>      >>
>      >>        What am I missing?  Is there anything else I need to
>      add to
>      >>        either
>      >>        build.conf or thinstation.conf.buildtime to be able to
>      efi boot
>      >>        from a usb
>      >>        drive with a static network configuration?
>      >>
>      >>        Thanks,
>      >>        Todd
>      >>
>      >>
>      >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>      >>
>      >>      >  This is all very interesting.  I looked at bt, and
>      flash, and
>      >>        mkgptdrv. Lots
>      >>      >  of archaeological excavation to do.
>      >>      >
>      >>      >  What is the current recommended way to write a UEFI
>      bootable
>      >>        USB drive from a
>      >>      >  command line in the chroot environment?  I don't want
>      to
>      >>        bother with
>      >>      >  Windows+rufus is I can possibly avoid that.
>      >>      >
>      >>      >  My guess is that I could either use your
>      /ts/bin/flash script,
>      >>        or I could use
>      >>      >  a command line similar to what I see in flash, using
>      mkgptdrv
>      >>        or mkmbrdrv.
>      >>      >  Correct?
>      >>      >
>      >>      >  In this particular case, since I need to UEFI boot, I
>      think I
>      >>        need mkgptdrv
>      >>      >  rather than mkmbrdrv.  Correct?
>      >>      >
>      >>      >  So, looking at your flash script, you have this entry
>      that
>      >>        uses mkgptdrv:
>      >>      >
>      >>      > systemd)
>      >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>      >>      >  /build/boot-images/systemd-boot-iso/efi-source
>      /dev/sdb
>      >>      >
>      >>      >
>      >>      >  which leads me to believe that I'll need
>      >>        boot-images/systemd-boot-iso, and
>      >>      >  based on what I see in the build script, this means
>      that I
>      >>        have to add
>      >>      >  systemd-boot-iso to param bootimages in build.conf. 
>      Correct?
>      >>      >
>      >>      >  In general, do you recommend just leaving param
>      bootimages
>      >>        empty so that the
>      >>      >  build script sets it to it's default as it does with
>      this
>      >>        code?
>      >>      >
>      >>      > if [ -z "$ts_bootimages" ]; then
>      >>      >         ts_bootimages="syslinux iso pxe refind-iso
>      >>        systemd-boot-iso grub"
>      >>      >
>      >>      >
>      >>      >  Is "systemd-boot-iso" the best option to use for my
>      use case
>      >>        of a UEFI
>      >>      >  bootable USB drive, or is there something else I
>      should
>      >>        consider that's
>      >>      >  already baked into the TS6.2 pie (and hopefully won't
>      require
>      >>        me to make too
>      >>      >  many more educated guesses :).
>      >>      >
>      >>      >  Thanks,
>      >>      >  Todd
>      >>      >
>      >>      >
>      >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>      >>      >
>      >>      >>   You can also open the file /ts/bin/bt in a text
>      editor and
>      >>        look at the
>      >>      >>   code I use for doing different things.
>      >>      >>
>      >>      >>   Have a look at
>      >>      >>
>      >>      >>   wrap_grub_efi() for some clues.
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>      >>        <don...@ya...>
>      >>      >>   wrote:
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   After doing a build, try 
>      >>      >>   bt net or bt net-efi
>      >>      >>   to test a pxe boot and possibly an install
>      >>      >>   afterwards,
>      >>      >>   bt image-grub to test your install
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>      via
>      >>        Thinstation-general
>      >>      >>   <thi...@li...> wrote:
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   I use fedora. It’s not the code, just how the
>      distro is
>      >>        handling umount.
>      >>      >>   You can see me calling it. On Ubuntu, if I don’t
>      use lazy
>      >>        umount, it hangs
>      >>      >>   the exit.
>      >>      >>
>      >>      >>
>      >>      >>   Sent from Yahoo Mail for iPhone
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>      >>        <pf...@rh...>
>      >>      >>   wrote:
>      >>      >>>   It's trivial.  I just run the following command
>      several
>      >>        times after I
>      >>      >>>   exit
>      >>      >>>   the setup-chroot shell.  It has become as quick as
>      a !for
>      >>        in my build
>      >>      >>>   shell.
>      >>      >>>
>      >>      >>>   for f in `mount|grep thinstation | awk '{print
>      $3}'`; do
>      >>        echo $f; umount
>      >>      >>>   $f; done
>      >>      >>>
>      >>      >>>
>      >>      >>>   So, no big deal, just unexpected.
>      >>      >>>
>      >>      >>>   If we're blaming this on the distro, that really
>      suprises
>      >>        me since you're
>      >>      >>>   basically saying that there are either very few
>      ThinStation
>      >>        users who are
>      >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>      other TS
>      >>        users who do
>      >>      >>>   use
>      >>      >>>   the same distro as me are just suffering in
>      silence. 
>      >>        Maybe, who knows.
>      >>      >>>   I'd also find it hard to believe this is distro
>      related
>      >>        given that
>      >>      >>>   setup-chroot is just bash code, and not terribly
>      complex
>      >>        bash code at
>      >>      >>>   that.  I'm curious now though: on what distro(s)
>      does this
>      >>        all work
>      >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>      to ease
>      >>        my pain.
>      >>      >>>
>      >>      >>>   Todd
>      >>      >>>
>      >>      >>>
>      >>      >>>   On Mon, 2 May 2022, Don Cupp via
>      Thinstation-general wrote:
>      >>      >>>
>      >>      >>>>   Oh the sadness of the various distro
>      peculiarities. How
>      >>        long does it
>      >>      >>>>   take to try and unmount everything?
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>      Pfaff
>      >>      >>>>   <pf...@rh...> wrote:
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>      2022-04-01.
>      >>      >>>>
>      >>      >>>>   I'm doing builds on a CentOS 7 host.
>      >>      >>>>
>      >>      >>>>   Something with setup-chroot is faulty.  When I
>      exit from
>      >>        setup-chroot,
>      >>      >>>>   it
>      >>      >>>>   does not unmount things like it's supposed to.  I
>      can
>      >>        clearly see the
>      >>      >>>>   code
>      >>      >>>>   in setup-chroot in function do_unmounts() that is
>      supposed
>      >>        to do
>      >>      >>>>   the unmount, and I can see from where this is
>      called, but
>      >>        it's not doing
>      >>      >>>>   its job.
>      >>      >>>>
>      >>      >>>>   This is then somehow leading to various
>      problems.  We've
>      >>        seen both /dev/
>      >>      >>>>   and /dev/pts/ go empty while I've been working
>      with ts6.2
>      >>        recently.
>      >>      >>>>
>      >>      >>>>   Todd
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   _______________________________________________
>      >>      >>>>   Thinstation-general mailing list
>      >>      >>>>   Thi...@li...
>      >>      >>>>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>
>      >>      >>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   _______________________________________________
>      >>      >>>>   Thinstation-general mailing list
>      >>      >>>>   Thi...@li...
>      >>      >>>>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>>>
>      >>      >>
>      >>      >>   _______________________________________________
>      >>      >>   Thinstation-general mailing list
>      >>      >>   Thi...@li...
>      >>      >>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>
>      >>      >>
>      >>      >
>      >>      >
>      >>
>      >>
>      >>
>      >
>      >
> 
> 
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Don C. <don...@ya...>]

So start without fastboot. It likely needs to know what volume name was assigned to the usb drive. 


Sent from Yahoo Mail for iPhone


On Wednesday, May 4, 2022, 2:50 PM, Todd Pfaff <pf...@rh...> wrote:

I can pxe boot ts6.2 on this same system and it works great.
Now I need to move it to a network location where I can't pxe boot it so I'm trying to get it working with the usb boot drive.



On May 4, 2022 5:39:42 p.m. Don Cupp <don...@ya...> wrote:

With network stacks?
What kind of network adapter?Possibly a firmware issue.


Sent from Yahoo Mail for iPhone


Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff <pf...@rh...> wrote:

Sorry, I just realized that I'd been using the wrong thread for this 
subject matter today.

I've changed my NET_ entries in build to conf to NET_IPV4 equivalents 
based on what I could find in various files under build/.  This is what I 
now have in thinstation.conf.buildtime:

NET_USE=LAN
NET_USE_DHCP=off
NET_HOSTNAME=tc1
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS1=8.8.8.8
NET_IPV4_DNS_SEARCH=mydomain.com


I then did a new build and then wrote my usb drive with:

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/grub/efi-source \
/dev/sdh


Boot fails in the same way as before, with the network unconfigured.

I tried again but with fastboot=false.

Same thing.  No network configuration.

I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg 
to look like this:

menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu 
--class os --unrestricted {
        set enable_progress_indicator=1
        linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM 
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24 
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS="1.1.1.1;2.2.2.2"
NET_IPV4_DNS_SEARCH="mydomain.com"
        initrd /boot/initrd
}


All those NET_ entries follow the LM=$LM on the same line, it's just split 
in this email.

Booted again, kernel loads, initrd loads, and sometime later it fails
in the same way, with no network configuration.

What could I possible be doing wrong now?


Btw, what does this syntax mean?

NET_HOSTNAME=tc_*


Thanks,
Todd


On Wed, 4 May 2022, Don Cupp wrote:

> Yep, your getting used to my organization already :)
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
> wrote:
>
>      I assume I should look here for details, yes?
>
>      [root@TS_chroot]/build# less
>      packages/autonet/etc/udev/scripts/net.sh
> 
>
>      or, if I were using the networkmanager package, look hereabouts?
>
>      ./packages/networkmanager/build/conf/64networkmanager
> 
> 
>
>      On Wed, 4 May 2022, Todd Pfaff wrote:
>
>      > omg.  I wish I'd asked earlier.  So sad for time wasted.
>      >
>      > I find plenty of old references to NET_(!IPV4)_stuff that I
>      was following. I
>      > have not yet come across a single googlematch that lead me in
>      the
>      > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>      under build/, I
>      > see.
>      >
>      > Anyway, thanks, better late than never. :)
>      >
>      >
>      > On Wed, 4 May 2022, Don Cupp wrote:
>      >
>      >>  I think it changed to NET_IPV4 prefix a few years back.
>      Where did you get
>      >>  that code? I’ll update it.
>      >>
>      >>  Sent from Yahoo Mail for iPhone
>      >>
>      >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>      <pf...@rh...>
>      >>  wrote:
>      >>
>      >>        I first tried this (my usb drive is sdh):
>      >>
>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>      >>        /build/boot-images/systemd-boot-iso/efi-source
>      /dev/sdh
>      >>
>      >>
>      >>        I then plugged that usb drive to my thinstation
>      machine and
>      >>        booted.  I had
>      >>        to add the uefi boot entry manually - it wasn't
>      autodetected -
>      >>        not sure if
>      >>        that is "normal".  Booting started but failed, I
>      think, because
>      >>        my network
>      >>        wasn't configured.  I'm aiming for a static network
>      >>        configuration in this
>      >>        case.
>      >>
>      >>        I next tried with refind:
>      >>
>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>      >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>      >>
>      >>
>      >>        Same dance, same failure mode - no network
>      configuration.
>      >>
>      >>
>      >>        I have this in my thinstation.conf.buildtime:
>      >>
>      >>        NET_HOSTNAME=tc003
>      >>        NET_IP_ADDRESS=192.168.1.2
>      >>        NET_GATEWAY=192.168.1.1
>      >>        NET_USE=LAN
>      >>        NET_USE_DHCP=false
>      >>        NET_MASK=255.255.255.0
>      >>        NET_DNS_SEARCH="mydomain.com"
>      >>        NET_DNS1=8.8.8.8
>      >>
>      >>
>      >>        What am I missing?  Is there anything else I need to
>      add to
>      >>        either
>      >>        build.conf or thinstation.conf.buildtime to be able to
>      efi boot
>      >>        from a usb
>      >>        drive with a static network configuration?
>      >>
>      >>        Thanks,
>      >>        Todd
>      >>
>      >>
>      >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>      >>
>      >>      >  This is all very interesting.  I looked at bt, and
>      flash, and
>      >>        mkgptdrv. Lots
>      >>      >  of archaeological excavation to do.
>      >>      >
>      >>      >  What is the current recommended way to write a UEFI
>      bootable
>      >>        USB drive from a
>      >>      >  command line in the chroot environment?  I don't want
>      to
>      >>        bother with
>      >>      >  Windows+rufus is I can possibly avoid that.
>      >>      >
>      >>      >  My guess is that I could either use your
>      /ts/bin/flash script,
>      >>        or I could use
>      >>      >  a command line similar to what I see in flash, using
>      mkgptdrv
>      >>        or mkmbrdrv.
>      >>      >  Correct?
>      >>      >
>      >>      >  In this particular case, since I need to UEFI boot, I
>      think I
>      >>        need mkgptdrv
>      >>      >  rather than mkmbrdrv.  Correct?
>      >>      >
>      >>      >  So, looking at your flash script, you have this entry
>      that
>      >>        uses mkgptdrv:
>      >>      >
>      >>      > systemd)
>      >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>      >>      >  /build/boot-images/systemd-boot-iso/efi-source
>      /dev/sdb
>      >>      >
>      >>      >
>      >>      >  which leads me to believe that I'll need
>      >>        boot-images/systemd-boot-iso, and
>      >>      >  based on what I see in the build script, this means
>      that I
>      >>        have to add
>      >>      >  systemd-boot-iso to param bootimages in build.conf. 
>      Correct?
>      >>      >
>      >>      >  In general, do you recommend just leaving param
>      bootimages
>      >>        empty so that the
>      >>      >  build script sets it to it's default as it does with
>      this
>      >>        code?
>      >>      >
>      >>      > if [ -z "$ts_bootimages" ]; then
>      >>      >         ts_bootimages="syslinux iso pxe refind-iso
>      >>        systemd-boot-iso grub"
>      >>      >
>      >>      >
>      >>      >  Is "systemd-boot-iso" the best option to use for my
>      use case
>      >>        of a UEFI
>      >>      >  bootable USB drive, or is there something else I
>      should
>      >>        consider that's
>      >>      >  already baked into the TS6.2 pie (and hopefully won't
>      require
>      >>        me to make too
>      >>      >  many more educated guesses :).
>      >>      >
>      >>      >  Thanks,
>      >>      >  Todd
>      >>      >
>      >>      >
>      >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>      >>      >
>      >>      >>   You can also open the file /ts/bin/bt in a text
>      editor and
>      >>        look at the
>      >>      >>   code I use for doing different things.
>      >>      >>
>      >>      >>   Have a look at
>      >>      >>
>      >>      >>   wrap_grub_efi() for some clues.
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>      >>        <don...@ya...>
>      >>      >>   wrote:
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   After doing a build, try 
>      >>      >>   bt net or bt net-efi
>      >>      >>   to test a pxe boot and possibly an install
>      >>      >>   afterwards,
>      >>      >>   bt image-grub to test your install
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>      via
>      >>        Thinstation-general
>      >>      >>   <thi...@li...> wrote:
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   I use fedora. It’s not the code, just how the
>      distro is
>      >>        handling umount.
>      >>      >>   You can see me calling it. On Ubuntu, if I don’t
>      use lazy
>      >>        umount, it hangs
>      >>      >>   the exit.
>      >>      >>
>      >>      >>
>      >>      >>   Sent from Yahoo Mail for iPhone
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>      >>        <pf...@rh...>
>      >>      >>   wrote:
>      >>      >>>   It's trivial.  I just run the following command
>      several
>      >>        times after I
>      >>      >>>   exit
>      >>      >>>   the setup-chroot shell.  It has become as quick as
>      a !for
>      >>        in my build
>      >>      >>>   shell.
>      >>      >>>
>      >>      >>>   for f in `mount|grep thinstation | awk '{print
>      $3}'`; do
>      >>        echo $f; umount
>      >>      >>>   $f; done
>      >>      >>>
>      >>      >>>
>      >>      >>>   So, no big deal, just unexpected.
>      >>      >>>
>      >>      >>>   If we're blaming this on the distro, that really
>      suprises
>      >>        me since you're
>      >>      >>>   basically saying that there are either very few
>      ThinStation
>      >>        users who are
>      >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>      other TS
>      >>        users who do
>      >>      >>>   use
>      >>      >>>   the same distro as me are just suffering in
>      silence. 
>      >>        Maybe, who knows.
>      >>      >>>   I'd also find it hard to believe this is distro
>      related
>      >>        given that
>      >>      >>>   setup-chroot is just bash code, and not terribly
>      complex
>      >>        bash code at
>      >>      >>>   that.  I'm curious now though: on what distro(s)
>      does this
>      >>        all work
>      >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>      to ease
>      >>        my pain.
>      >>      >>>
>      >>      >>>   Todd
>      >>      >>>
>      >>      >>>
>      >>      >>>   On Mon, 2 May 2022, Don Cupp via
>      Thinstation-general wrote:
>      >>      >>>
>      >>      >>>>   Oh the sadness of the various distro
>      peculiarities. How
>      >>        long does it
>      >>      >>>>   take to try and unmount everything?
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>      Pfaff
>      >>      >>>>   <pf...@rh...> wrote:
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>      2022-04-01.
>      >>      >>>>
>      >>      >>>>   I'm doing builds on a CentOS 7 host.
>      >>      >>>>
>      >>      >>>>   Something with setup-chroot is faulty.  When I
>      exit from
>      >>        setup-chroot,
>      >>      >>>>   it
>      >>      >>>>   does not unmount things like it's supposed to.  I
>      can
>      >>        clearly see the
>      >>      >>>>   code
>      >>      >>>>   in setup-chroot in function do_unmounts() that is
>      supposed
>      >>        to do
>      >>      >>>>   the unmount, and I can see from where this is
>      called, but
>      >>        it's not doing
>      >>      >>>>   its job.
>      >>      >>>>
>      >>      >>>>   This is then somehow leading to various
>      problems.  We've
>      >>        seen both /dev/
>      >>      >>>>   and /dev/pts/ go empty while I've been working
>      with ts6.2
>      >>        recently.
>      >>      >>>>
>      >>      >>>>   Todd
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   _______________________________________________
>      >>      >>>>   Thinstation-general mailing list
>      >>      >>>>   Thi...@li...
>      >>      >>>>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>
>      >>      >>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   _______________________________________________
>      >>      >>>>   Thinstation-general mailing list
>      >>      >>>>   Thi...@li...
>      >>      >>>>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>>>
>      >>      >>
>      >>      >>   _______________________________________________
>      >>      >>   Thinstation-general mailing list
>      >>      >>   Thi...@li...
>      >>      >>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>
>      >>      >>
>      >>      >
>      >>      >
>      >>
>      >>
>      >>
>      >
>      >
> 
> 
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

Sorry, what do you mean by "with network stacks?"?

I'll check the net device and get back to you, but given that it works when 
pxe booting, it's unlikely a firmware or driver issue (except maybe the 
driver isn't loaded ... But why?)


On May 4, 2022 5:39:42 p.m. Don Cupp <don...@ya...> wrote:
> With network stacks?
>
> What kind of network adapter?
> Possibly a firmware issue.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff 
> <pf...@rh...> wrote:
> Sorry, I just realized that I'd been using the wrong thread for this
> subject matter today.
>
> I've changed my NET_ entries in build to conf to NET_IPV4 equivalents
> based on what I could find in various files under build/.  This is what I
> now have in thinstation.conf.buildtime:
>
> NET_USE=LAN
> NET_USE_DHCP=off
> NET_HOSTNAME=tc1
> NET_IPV4_MODE=manual
> NET_IPV4_ADDRESS=192.168.1.2/24
> NET_IPV4_GATEWAY=192.168.1.1
> NET_IPV4_DNS1=8.8.8.8
> NET_IPV4_DNS_SEARCH=mydomain.com
>
>
> I then did a new build and then wrote my usb drive with:
>
> mkgptdrv -p ESP:2g:boot -p l:0:home -o \
> /build/boot-images/grub/efi-source \
> /dev/sdh
>
>
> Boot fails in the same way as before, with the network unconfigured.
>
> I tried again but with fastboot=false.
>
> Same thing.  No network configuration.
>
> I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
> That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg
> to look like this:
>
> menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu
> --class os --unrestricted {
> set enable_progress_indicator=1
> linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM
> NET_IPV4_MODE=manual
> NET_IPV4_ADDRESS=192.168.1.2/24
> NET_IPV4_GATEWAY=192.168.1.1
> NET_IPV4_DNS="1.1.1.1;2.2.2.2"
> NET_IPV4_DNS_SEARCH="mydomain.com"
> initrd /boot/initrd
> }
>
>
> All those NET_ entries follow the LM=$LM on the same line, it's just split
> in this email.
>
> Booted again, kernel loads, initrd loads, and sometime later it fails
> in the same way, with no network configuration.
>
> What could I possible be doing wrong now?
>
>
> Btw, what does this syntax mean?
>
> NET_HOSTNAME=tc_*
>
>
> Thanks,
> Todd
>
>
>
> On Wed, 4 May 2022, Don Cupp wrote:
>
>> Yep, your getting used to my organization already :)
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
>> wrote:
>>
>>      I assume I should look here for details, yes?
>>
>>      [root@TS_chroot]/build# less
>>      packages/autonet/etc/udev/scripts/net.sh
>>
>>
>>      or, if I were using the networkmanager package, look hereabouts?
>>
>>      ./packages/networkmanager/build/conf/64networkmanager
>>
>>
>>
>>      On Wed, 4 May 2022, Todd Pfaff wrote:
>>
>>      > omg.  I wish I'd asked earlier.  So sad for time wasted.
>>      >
>>      > I find plenty of old references to NET_(!IPV4)_stuff that I
>>      was following. I
>>      > have not yet come across a single googlematch that lead me in
>>      the
>>      > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>>      under build/, I
>>      > see.
>>      >
>>      > Anyway, thanks, better late than never. :)
>>      >
>>      >
>>      > On Wed, 4 May 2022, Don Cupp wrote:
>>      >
>>      >>  I think it changed to NET_IPV4 prefix a few years back.
>>      Where did you get
>>      >>  that code? I’ll update it.
>>      >>
>>      >>  Sent from Yahoo Mail for iPhone
>>      >>
>>      >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>>      <pf...@rh...>
>>      >>  wrote:
>>      >>
>>      >>        I first tried this (my usb drive is sdh):
>>      >>
>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>      >>        /build/boot-images/systemd-boot-iso/efi-source
>>      /dev/sdh
>>      >>
>>      >>
>>      >>        I then plugged that usb drive to my thinstation
>>      machine and
>>      >>        booted.  I had
>>      >>        to add the uefi boot entry manually - it wasn't
>>      autodetected -
>>      >>        not sure if
>>      >>        that is "normal".  Booting started but failed, I
>>      think, because
>>      >>        my network
>>      >>        wasn't configured.  I'm aiming for a static network
>>      >>        configuration in this
>>      >>        case.
>>      >>
>>      >>        I next tried with refind:
>>      >>
>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>      >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>>      >>
>>      >>
>>      >>        Same dance, same failure mode - no network
>>      configuration.
>>      >>
>>      >>
>>      >>        I have this in my thinstation.conf.buildtime:
>>      >>
>>      >>        NET_HOSTNAME=tc003
>>      >>        NET_IP_ADDRESS=192.168.1.2
>>      >>        NET_GATEWAY=192.168.1.1
>>      >>        NET_USE=LAN
>>      >>        NET_USE_DHCP=false
>>      >>        NET_MASK=255.255.255.0
>>      >>        NET_DNS_SEARCH="mydomain.com"
>>      >>        NET_DNS1=8.8.8.8
>>      >>
>>      >>
>>      >>        What am I missing?  Is there anything else I need to
>>      add to
>>      >>        either
>>      >>        build.conf or thinstation.conf.buildtime to be able to
>>      efi boot
>>      >>        from a usb
>>      >>        drive with a static network configuration?
>>      >>
>>      >>        Thanks,
>>      >>        Todd
>>      >>
>>      >>
>>      >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>>      >>
>>      >>      >  This is all very interesting.  I looked at bt, and
>>      flash, and
>>      >>        mkgptdrv. Lots
>>      >>      >  of archaeological excavation to do.
>>      >>      >
>>      >>      >  What is the current recommended way to write a UEFI
>>      bootable
>>      >>        USB drive from a
>>      >>      >  command line in the chroot environment?  I don't want
>>      to
>>      >>        bother with
>>      >>      >  Windows+rufus is I can possibly avoid that.
>>      >>      >
>>      >>      >  My guess is that I could either use your
>>      /ts/bin/flash script,
>>      >>        or I could use
>>      >>      >  a command line similar to what I see in flash, using
>>      mkgptdrv
>>      >>        or mkmbrdrv.
>>      >>      >  Correct?
>>      >>      >
>>      >>      >  In this particular case, since I need to UEFI boot, I
>>      think I
>>      >>        need mkgptdrv
>>      >>      >  rather than mkmbrdrv.  Correct?
>>      >>      >
>>      >>      >  So, looking at your flash script, you have this entry
>>      that
>>      >>        uses mkgptdrv:
>>      >>      >
>>      >>      > systemd)
>>      >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>>      >>      >  /build/boot-images/systemd-boot-iso/efi-source
>>      /dev/sdb
>>      >>      >
>>      >>      >
>>      >>      >  which leads me to believe that I'll need
>>      >>        boot-images/systemd-boot-iso, and
>>      >>      >  based on what I see in the build script, this means
>>      that I
>>      >>        have to add
>>      >>      >  systemd-boot-iso to param bootimages in build.conf.
>>      Correct?
>>      >>      >
>>      >>      >  In general, do you recommend just leaving param
>>      bootimages
>>      >>        empty so that the
>>      >>      >  build script sets it to it's default as it does with
>>      this
>>      >>        code?
>>      >>      >
>>      >>      > if [ -z "$ts_bootimages" ]; then
>>      >>      >         ts_bootimages="syslinux iso pxe refind-iso
>>      >>        systemd-boot-iso grub"
>>      >>      >
>>      >>      >
>>      >>      >  Is "systemd-boot-iso" the best option to use for my
>>      use case
>>      >>        of a UEFI
>>      >>      >  bootable USB drive, or is there something else I
>>      should
>>      >>        consider that's
>>      >>      >  already baked into the TS6.2 pie (and hopefully won't
>>      require
>>      >>        me to make too
>>      >>      >  many more educated guesses :).
>>      >>      >
>>      >>      >  Thanks,
>>      >>      >  Todd
>>      >>      >
>>      >>      >
>>      >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>>      >>      >
>>      >>      >>   You can also open the file /ts/bin/bt in a text
>>      editor and
>>      >>        look at the
>>      >>      >>   code I use for doing different things.
>>      >>      >>
>>      >>      >>   Have a look at
>>      >>      >>
>>      >>      >>   wrap_grub_efi() for some clues.
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>>      >>        <don...@ya...>
>>      >>      >>   wrote:
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   After doing a build, try
>>      >>      >>   bt net or bt net-efi
>>      >>      >>   to test a pxe boot and possibly an install
>>      >>      >>   afterwards,
>>      >>      >>   bt image-grub to test your install
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>>      via
>>      >>        Thinstation-general
>>      >>      >>   <thi...@li...> wrote:
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   I use fedora. It’s not the code, just how the
>>      distro is
>>      >>        handling umount.
>>      >>      >>   You can see me calling it. On Ubuntu, if I don’t
>>      use lazy
>>      >>        umount, it hangs
>>      >>      >>   the exit.
>>      >>      >>
>>      >>      >>
>>      >>      >>   Sent from Yahoo Mail for iPhone
>>      >>      >>
>>      >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>>      >>        <pf...@rh...>
>>      >>      >>   wrote:
>>      >>      >>>   It's trivial.  I just run the following command
>>      several
>>      >>        times after I
>>      >>      >>>   exit
>>      >>      >>>   the setup-chroot shell.  It has become as quick as
>>      a !for
>>      >>        in my build
>>      >>      >>>   shell.
>>      >>      >>>
>>      >>      >>>   for f in `mount|grep thinstation | awk '{print
>>      $3}'`; do
>>      >>        echo $f; umount
>>      >>      >>>   $f; done
>>      >>      >>>
>>      >>      >>>
>>      >>      >>>   So, no big deal, just unexpected.
>>      >>      >>>
>>      >>      >>>   If we're blaming this on the distro, that really
>>      suprises
>>      >>        me since you're
>>      >>      >>>   basically saying that there are either very few
>>      ThinStation
>>      >>        users who are
>>      >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>>      other TS
>>      >>        users who do
>>      >>      >>>   use
>>      >>      >>>   the same distro as me are just suffering in
>>      silence.
>>      >>        Maybe, who knows.
>>      >>      >>>   I'd also find it hard to believe this is distro
>>      related
>>      >>        given that
>>      >>      >>>   setup-chroot is just bash code, and not terribly
>>      complex
>>      >>        bash code at
>>      >>      >>>   that.  I'm curious now though: on what distro(s)
>>      does this
>>      >>        all work
>>      >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>>      to ease
>>      >>        my pain.
>>      >>      >>>
>>      >>      >>>   Todd
>>      >>      >>>
>>      >>      >>>
>>      >>      >>>   On Mon, 2 May 2022, Don Cupp via
>>      Thinstation-general wrote:
>>      >>      >>>
>>      >>      >>>>   Oh the sadness of the various distro
>>      peculiarities. How
>>      >>        long does it
>>      >>      >>>>   take to try and unmount everything?
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>>      Pfaff
>>      >>      >>>>   <pf...@rh...> wrote:
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>>      2022-04-01.
>>      >>      >>>>
>>      >>      >>>>   I'm doing builds on a CentOS 7 host.
>>      >>      >>>>
>>      >>      >>>>   Something with setup-chroot is faulty.  When I
>>      exit from
>>      >>        setup-chroot,
>>      >>      >>>>   it
>>      >>      >>>>   does not unmount things like it's supposed to.  I
>>      can
>>      >>        clearly see the
>>      >>      >>>>   code
>>      >>      >>>>   in setup-chroot in function do_unmounts() that is
>>      supposed
>>      >>        to do
>>      >>      >>>>   the unmount, and I can see from where this is
>>      called, but
>>      >>        it's not doing
>>      >>      >>>>   its job.
>>      >>      >>>>
>>      >>      >>>>   This is then somehow leading to various
>>      problems.  We've
>>      >>        seen both /dev/
>>      >>      >>>>   and /dev/pts/ go empty while I've been working
>>      with ts6.2
>>      >>        recently.
>>      >>      >>>>
>>      >>      >>>>   Todd
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   _______________________________________________
>>      >>      >>>>   Thinstation-general mailing list
>>      >>      >>>>   Thi...@li...
>>      >>      >>>>
>>      >>
>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>      >>
>>      >>      >>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   _______________________________________________
>>      >>      >>>>   Thinstation-general mailing list
>>      >>      >>>>   Thi...@li...
>>      >>      >>>>
>>      >>
>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>      >>>>
>>      >>      >>
>>      >>      >>   _______________________________________________
>>      >>      >>   Thinstation-general mailing list
>>      >>      >>   Thi...@li...
>>      >>      >>
>>      >>
>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>      >>
>>      >>      >>
>>      >>      >
>>      >>      >
>>      >>
>>      >>
>>      >>
>>      >
>>      >
>>
>>
>>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

I can pxe boot ts6.2 on this same system and it works great.

Now I need to move it to a network location where I can't pxe boot it so 
I'm trying to get it working with the usb boot drive.



On May 4, 2022 5:39:42 p.m. Don Cupp <don...@ya...> wrote:
> With network stacks?
>
> What kind of network adapter?
> Possibly a firmware issue.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff 
> <pf...@rh...> wrote:
> Sorry, I just realized that I'd been using the wrong thread for this
> subject matter today.
>
> I've changed my NET_ entries in build to conf to NET_IPV4 equivalents
> based on what I could find in various files under build/.  This is what I
> now have in thinstation.conf.buildtime:
>
> NET_USE=LAN
> NET_USE_DHCP=off
> NET_HOSTNAME=tc1
> NET_IPV4_MODE=manual
> NET_IPV4_ADDRESS=192.168.1.2/24
> NET_IPV4_GATEWAY=192.168.1.1
> NET_IPV4_DNS1=8.8.8.8
> NET_IPV4_DNS_SEARCH=mydomain.com
>
>
> I then did a new build and then wrote my usb drive with:
>
> mkgptdrv -p ESP:2g:boot -p l:0:home -o \
> /build/boot-images/grub/efi-source \
> /dev/sdh
>
>
> Boot fails in the same way as before, with the network unconfigured.
>
> I tried again but with fastboot=false.
>
> Same thing.  No network configuration.
>
> I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
> That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg
> to look like this:
>
> menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu
> --class os --unrestricted {
> set enable_progress_indicator=1
> linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM
> NET_IPV4_MODE=manual
> NET_IPV4_ADDRESS=192.168.1.2/24
> NET_IPV4_GATEWAY=192.168.1.1
> NET_IPV4_DNS="1.1.1.1;2.2.2.2"
> NET_IPV4_DNS_SEARCH="mydomain.com"
> initrd /boot/initrd
> }
>
>
> All those NET_ entries follow the LM=$LM on the same line, it's just split
> in this email.
>
> Booted again, kernel loads, initrd loads, and sometime later it fails
> in the same way, with no network configuration.
>
> What could I possible be doing wrong now?
>
>
> Btw, what does this syntax mean?
>
> NET_HOSTNAME=tc_*
>
>
> Thanks,
> Todd
>
>
>
> On Wed, 4 May 2022, Don Cupp wrote:
>
>> Yep, your getting used to my organization already :)
>>
>>
>> Sent from Yahoo Mail for iPhone
>>
>> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
>> wrote:
>>
>>      I assume I should look here for details, yes?
>>
>>      [root@TS_chroot]/build# less
>>      packages/autonet/etc/udev/scripts/net.sh
>>
>>
>>      or, if I were using the networkmanager package, look hereabouts?
>>
>>      ./packages/networkmanager/build/conf/64networkmanager
>>
>>
>>
>>      On Wed, 4 May 2022, Todd Pfaff wrote:
>>
>>      > omg.  I wish I'd asked earlier.  So sad for time wasted.
>>      >
>>      > I find plenty of old references to NET_(!IPV4)_stuff that I
>>      was following. I
>>      > have not yet come across a single googlematch that lead me in
>>      the
>>      > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>>      under build/, I
>>      > see.
>>      >
>>      > Anyway, thanks, better late than never. :)
>>      >
>>      >
>>      > On Wed, 4 May 2022, Don Cupp wrote:
>>      >
>>      >>  I think it changed to NET_IPV4 prefix a few years back.
>>      Where did you get
>>      >>  that code? I’ll update it.
>>      >>
>>      >>  Sent from Yahoo Mail for iPhone
>>      >>
>>      >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>>      <pf...@rh...>
>>      >>  wrote:
>>      >>
>>      >>        I first tried this (my usb drive is sdh):
>>      >>
>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>      >>        /build/boot-images/systemd-boot-iso/efi-source
>>      /dev/sdh
>>      >>
>>      >>
>>      >>        I then plugged that usb drive to my thinstation
>>      machine and
>>      >>        booted.  I had
>>      >>        to add the uefi boot entry manually - it wasn't
>>      autodetected -
>>      >>        not sure if
>>      >>        that is "normal".  Booting started but failed, I
>>      think, because
>>      >>        my network
>>      >>        wasn't configured.  I'm aiming for a static network
>>      >>        configuration in this
>>      >>        case.
>>      >>
>>      >>        I next tried with refind:
>>      >>
>>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>      >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>>      >>
>>      >>
>>      >>        Same dance, same failure mode - no network
>>      configuration.
>>      >>
>>      >>
>>      >>        I have this in my thinstation.conf.buildtime:
>>      >>
>>      >>        NET_HOSTNAME=tc003
>>      >>        NET_IP_ADDRESS=192.168.1.2
>>      >>        NET_GATEWAY=192.168.1.1
>>      >>        NET_USE=LAN
>>      >>        NET_USE_DHCP=false
>>      >>        NET_MASK=255.255.255.0
>>      >>        NET_DNS_SEARCH="mydomain.com"
>>      >>        NET_DNS1=8.8.8.8
>>      >>
>>      >>
>>      >>        What am I missing?  Is there anything else I need to
>>      add to
>>      >>        either
>>      >>        build.conf or thinstation.conf.buildtime to be able to
>>      efi boot
>>      >>        from a usb
>>      >>        drive with a static network configuration?
>>      >>
>>      >>        Thanks,
>>      >>        Todd
>>      >>
>>      >>
>>      >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>>      >>
>>      >>      >  This is all very interesting.  I looked at bt, and
>>      flash, and
>>      >>        mkgptdrv. Lots
>>      >>      >  of archaeological excavation to do.
>>      >>      >
>>      >>      >  What is the current recommended way to write a UEFI
>>      bootable
>>      >>        USB drive from a
>>      >>      >  command line in the chroot environment?  I don't want
>>      to
>>      >>        bother with
>>      >>      >  Windows+rufus is I can possibly avoid that.
>>      >>      >
>>      >>      >  My guess is that I could either use your
>>      /ts/bin/flash script,
>>      >>        or I could use
>>      >>      >  a command line similar to what I see in flash, using
>>      mkgptdrv
>>      >>        or mkmbrdrv.
>>      >>      >  Correct?
>>      >>      >
>>      >>      >  In this particular case, since I need to UEFI boot, I
>>      think I
>>      >>        need mkgptdrv
>>      >>      >  rather than mkmbrdrv.  Correct?
>>      >>      >
>>      >>      >  So, looking at your flash script, you have this entry
>>      that
>>      >>        uses mkgptdrv:
>>      >>      >
>>      >>      > systemd)
>>      >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>>      >>      >  /build/boot-images/systemd-boot-iso/efi-source
>>      /dev/sdb
>>      >>      >
>>      >>      >
>>      >>      >  which leads me to believe that I'll need
>>      >>        boot-images/systemd-boot-iso, and
>>      >>      >  based on what I see in the build script, this means
>>      that I
>>      >>        have to add
>>      >>      >  systemd-boot-iso to param bootimages in build.conf.
>>      Correct?
>>      >>      >
>>      >>      >  In general, do you recommend just leaving param
>>      bootimages
>>      >>        empty so that the
>>      >>      >  build script sets it to it's default as it does with
>>      this
>>      >>        code?
>>      >>      >
>>      >>      > if [ -z "$ts_bootimages" ]; then
>>      >>      >         ts_bootimages="syslinux iso pxe refind-iso
>>      >>        systemd-boot-iso grub"
>>      >>      >
>>      >>      >
>>      >>      >  Is "systemd-boot-iso" the best option to use for my
>>      use case
>>      >>        of a UEFI
>>      >>      >  bootable USB drive, or is there something else I
>>      should
>>      >>        consider that's
>>      >>      >  already baked into the TS6.2 pie (and hopefully won't
>>      require
>>      >>        me to make too
>>      >>      >  many more educated guesses :).
>>      >>      >
>>      >>      >  Thanks,
>>      >>      >  Todd
>>      >>      >
>>      >>      >
>>      >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>>      >>      >
>>      >>      >>   You can also open the file /ts/bin/bt in a text
>>      editor and
>>      >>        look at the
>>      >>      >>   code I use for doing different things.
>>      >>      >>
>>      >>      >>   Have a look at
>>      >>      >>
>>      >>      >>   wrap_grub_efi() for some clues.
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>>      >>        <don...@ya...>
>>      >>      >>   wrote:
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   After doing a build, try
>>      >>      >>   bt net or bt net-efi
>>      >>      >>   to test a pxe boot and possibly an install
>>      >>      >>   afterwards,
>>      >>      >>   bt image-grub to test your install
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>>      via
>>      >>        Thinstation-general
>>      >>      >>   <thi...@li...> wrote:
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>
>>      >>      >>   I use fedora. It’s not the code, just how the
>>      distro is
>>      >>        handling umount.
>>      >>      >>   You can see me calling it. On Ubuntu, if I don’t
>>      use lazy
>>      >>        umount, it hangs
>>      >>      >>   the exit.
>>      >>      >>
>>      >>      >>
>>      >>      >>   Sent from Yahoo Mail for iPhone
>>      >>      >>
>>      >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>>      >>        <pf...@rh...>
>>      >>      >>   wrote:
>>      >>      >>>   It's trivial.  I just run the following command
>>      several
>>      >>        times after I
>>      >>      >>>   exit
>>      >>      >>>   the setup-chroot shell.  It has become as quick as
>>      a !for
>>      >>        in my build
>>      >>      >>>   shell.
>>      >>      >>>
>>      >>      >>>   for f in `mount|grep thinstation | awk '{print
>>      $3}'`; do
>>      >>        echo $f; umount
>>      >>      >>>   $f; done
>>      >>      >>>
>>      >>      >>>
>>      >>      >>>   So, no big deal, just unexpected.
>>      >>      >>>
>>      >>      >>>   If we're blaming this on the distro, that really
>>      suprises
>>      >>        me since you're
>>      >>      >>>   basically saying that there are either very few
>>      ThinStation
>>      >>        users who are
>>      >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>>      other TS
>>      >>        users who do
>>      >>      >>>   use
>>      >>      >>>   the same distro as me are just suffering in
>>      silence.
>>      >>        Maybe, who knows.
>>      >>      >>>   I'd also find it hard to believe this is distro
>>      related
>>      >>        given that
>>      >>      >>>   setup-chroot is just bash code, and not terribly
>>      complex
>>      >>        bash code at
>>      >>      >>>   that.  I'm curious now though: on what distro(s)
>>      does this
>>      >>        all work
>>      >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>>      to ease
>>      >>        my pain.
>>      >>      >>>
>>      >>      >>>   Todd
>>      >>      >>>
>>      >>      >>>
>>      >>      >>>   On Mon, 2 May 2022, Don Cupp via
>>      Thinstation-general wrote:
>>      >>      >>>
>>      >>      >>>>   Oh the sadness of the various distro
>>      peculiarities. How
>>      >>        long does it
>>      >>      >>>>   take to try and unmount everything?
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>>      Pfaff
>>      >>      >>>>   <pf...@rh...> wrote:
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>>      2022-04-01.
>>      >>      >>>>
>>      >>      >>>>   I'm doing builds on a CentOS 7 host.
>>      >>      >>>>
>>      >>      >>>>   Something with setup-chroot is faulty.  When I
>>      exit from
>>      >>        setup-chroot,
>>      >>      >>>>   it
>>      >>      >>>>   does not unmount things like it's supposed to.  I
>>      can
>>      >>        clearly see the
>>      >>      >>>>   code
>>      >>      >>>>   in setup-chroot in function do_unmounts() that is
>>      supposed
>>      >>        to do
>>      >>      >>>>   the unmount, and I can see from where this is
>>      called, but
>>      >>        it's not doing
>>      >>      >>>>   its job.
>>      >>      >>>>
>>      >>      >>>>   This is then somehow leading to various
>>      problems.  We've
>>      >>        seen both /dev/
>>      >>      >>>>   and /dev/pts/ go empty while I've been working
>>      with ts6.2
>>      >>        recently.
>>      >>      >>>>
>>      >>      >>>>   Todd
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   _______________________________________________
>>      >>      >>>>   Thinstation-general mailing list
>>      >>      >>>>   Thi...@li...
>>      >>      >>>>
>>      >>
>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>      >>
>>      >>      >>>
>>      >>      >>>>
>>      >>      >>>>
>>      >>      >>>>   _______________________________________________
>>      >>      >>>>   Thinstation-general mailing list
>>      >>      >>>>   Thi...@li...
>>      >>      >>>>
>>      >>
>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>      >>>>
>>      >>      >>
>>      >>      >>   _______________________________________________
>>      >>      >>   Thinstation-general mailing list
>>      >>      >>   Thi...@li...
>>      >>      >>
>>      >>
>>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>      >>
>>      >>      >>
>>      >>      >
>>      >>      >
>>      >>
>>      >>
>>      >>
>>      >
>>      >
>>
>>
>>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Don C. <don...@ya...>]

With network stacks?
What kind of network adapter?Possibly a firmware issue.


Sent from Yahoo Mail for iPhone


Acid On Wednesday, May 4, 2022, 2:21 PM, Todd Pfaff <pf...@rh...> wrote:

Sorry, I just realized that I'd been using the wrong thread for this 
subject matter today.

I've changed my NET_ entries in build to conf to NET_IPV4 equivalents 
based on what I could find in various files under build/.  This is what I 
now have in thinstation.conf.buildtime:

NET_USE=LAN
NET_USE_DHCP=off
NET_HOSTNAME=tc1
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS1=8.8.8.8
NET_IPV4_DNS_SEARCH=mydomain.com


I then did a new build and then wrote my usb drive with:

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/grub/efi-source \
/dev/sdh


Boot fails in the same way as before, with the network unconfigured.

I tried again but with fastboot=false.

Same thing.  No network configuration.

I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg 
to look like this:

menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu 
--class os --unrestricted {
        set enable_progress_indicator=1
        linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM 
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24 
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS="1.1.1.1;2.2.2.2"
NET_IPV4_DNS_SEARCH="mydomain.com"
        initrd /boot/initrd
}


All those NET_ entries follow the LM=$LM on the same line, it's just split 
in this email.

Booted again, kernel loads, initrd loads, and sometime later it fails
in the same way, with no network configuration.

What could I possible be doing wrong now?


Btw, what does this syntax mean?

NET_HOSTNAME=tc_*


Thanks,
Todd


On Wed, 4 May 2022, Don Cupp wrote:

> Yep, your getting used to my organization already :)
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
> wrote:
>
>      I assume I should look here for details, yes?
>
>      [root@TS_chroot]/build# less
>      packages/autonet/etc/udev/scripts/net.sh
> 
>
>      or, if I were using the networkmanager package, look hereabouts?
>
>      ./packages/networkmanager/build/conf/64networkmanager
> 
> 
>
>      On Wed, 4 May 2022, Todd Pfaff wrote:
>
>      > omg.  I wish I'd asked earlier.  So sad for time wasted.
>      >
>      > I find plenty of old references to NET_(!IPV4)_stuff that I
>      was following. I
>      > have not yet come across a single googlematch that lead me in
>      the
>      > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>      under build/, I
>      > see.
>      >
>      > Anyway, thanks, better late than never. :)
>      >
>      >
>      > On Wed, 4 May 2022, Don Cupp wrote:
>      >
>      >>  I think it changed to NET_IPV4 prefix a few years back.
>      Where did you get
>      >>  that code? I’ll update it.
>      >>
>      >>  Sent from Yahoo Mail for iPhone
>      >>
>      >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>      <pf...@rh...>
>      >>  wrote:
>      >>
>      >>        I first tried this (my usb drive is sdh):
>      >>
>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>      >>        /build/boot-images/systemd-boot-iso/efi-source
>      /dev/sdh
>      >>
>      >>
>      >>        I then plugged that usb drive to my thinstation
>      machine and
>      >>        booted.  I had
>      >>        to add the uefi boot entry manually - it wasn't
>      autodetected -
>      >>        not sure if
>      >>        that is "normal".  Booting started but failed, I
>      think, because
>      >>        my network
>      >>        wasn't configured.  I'm aiming for a static network
>      >>        configuration in this
>      >>        case.
>      >>
>      >>        I next tried with refind:
>      >>
>      >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>      >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>      >>
>      >>
>      >>        Same dance, same failure mode - no network
>      configuration.
>      >>
>      >>
>      >>        I have this in my thinstation.conf.buildtime:
>      >>
>      >>        NET_HOSTNAME=tc003
>      >>        NET_IP_ADDRESS=192.168.1.2
>      >>        NET_GATEWAY=192.168.1.1
>      >>        NET_USE=LAN
>      >>        NET_USE_DHCP=false
>      >>        NET_MASK=255.255.255.0
>      >>        NET_DNS_SEARCH="mydomain.com"
>      >>        NET_DNS1=8.8.8.8
>      >>
>      >>
>      >>        What am I missing?  Is there anything else I need to
>      add to
>      >>        either
>      >>        build.conf or thinstation.conf.buildtime to be able to
>      efi boot
>      >>        from a usb
>      >>        drive with a static network configuration?
>      >>
>      >>        Thanks,
>      >>        Todd
>      >>
>      >>
>      >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>      >>
>      >>      >  This is all very interesting.  I looked at bt, and
>      flash, and
>      >>        mkgptdrv. Lots
>      >>      >  of archaeological excavation to do.
>      >>      >
>      >>      >  What is the current recommended way to write a UEFI
>      bootable
>      >>        USB drive from a
>      >>      >  command line in the chroot environment?  I don't want
>      to
>      >>        bother with
>      >>      >  Windows+rufus is I can possibly avoid that.
>      >>      >
>      >>      >  My guess is that I could either use your
>      /ts/bin/flash script,
>      >>        or I could use
>      >>      >  a command line similar to what I see in flash, using
>      mkgptdrv
>      >>        or mkmbrdrv.
>      >>      >  Correct?
>      >>      >
>      >>      >  In this particular case, since I need to UEFI boot, I
>      think I
>      >>        need mkgptdrv
>      >>      >  rather than mkmbrdrv.  Correct?
>      >>      >
>      >>      >  So, looking at your flash script, you have this entry
>      that
>      >>        uses mkgptdrv:
>      >>      >
>      >>      > systemd)
>      >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>      >>      >  /build/boot-images/systemd-boot-iso/efi-source
>      /dev/sdb
>      >>      >
>      >>      >
>      >>      >  which leads me to believe that I'll need
>      >>        boot-images/systemd-boot-iso, and
>      >>      >  based on what I see in the build script, this means
>      that I
>      >>        have to add
>      >>      >  systemd-boot-iso to param bootimages in build.conf. 
>      Correct?
>      >>      >
>      >>      >  In general, do you recommend just leaving param
>      bootimages
>      >>        empty so that the
>      >>      >  build script sets it to it's default as it does with
>      this
>      >>        code?
>      >>      >
>      >>      > if [ -z "$ts_bootimages" ]; then
>      >>      >         ts_bootimages="syslinux iso pxe refind-iso
>      >>        systemd-boot-iso grub"
>      >>      >
>      >>      >
>      >>      >  Is "systemd-boot-iso" the best option to use for my
>      use case
>      >>        of a UEFI
>      >>      >  bootable USB drive, or is there something else I
>      should
>      >>        consider that's
>      >>      >  already baked into the TS6.2 pie (and hopefully won't
>      require
>      >>        me to make too
>      >>      >  many more educated guesses :).
>      >>      >
>      >>      >  Thanks,
>      >>      >  Todd
>      >>      >
>      >>      >
>      >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>      >>      >
>      >>      >>   You can also open the file /ts/bin/bt in a text
>      editor and
>      >>        look at the
>      >>      >>   code I use for doing different things.
>      >>      >>
>      >>      >>   Have a look at
>      >>      >>
>      >>      >>   wrap_grub_efi() for some clues.
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>      >>        <don...@ya...>
>      >>      >>   wrote:
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   After doing a build, try 
>      >>      >>   bt net or bt net-efi
>      >>      >>   to test a pxe boot and possibly an install
>      >>      >>   afterwards,
>      >>      >>   bt image-grub to test your install
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>      via
>      >>        Thinstation-general
>      >>      >>   <thi...@li...> wrote:
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>
>      >>      >>   I use fedora. It’s not the code, just how the
>      distro is
>      >>        handling umount.
>      >>      >>   You can see me calling it. On Ubuntu, if I don’t
>      use lazy
>      >>        umount, it hangs
>      >>      >>   the exit.
>      >>      >>
>      >>      >>
>      >>      >>   Sent from Yahoo Mail for iPhone
>      >>      >>
>      >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>      >>        <pf...@rh...>
>      >>      >>   wrote:
>      >>      >>>   It's trivial.  I just run the following command
>      several
>      >>        times after I
>      >>      >>>   exit
>      >>      >>>   the setup-chroot shell.  It has become as quick as
>      a !for
>      >>        in my build
>      >>      >>>   shell.
>      >>      >>>
>      >>      >>>   for f in `mount|grep thinstation | awk '{print
>      $3}'`; do
>      >>        echo $f; umount
>      >>      >>>   $f; done
>      >>      >>>
>      >>      >>>
>      >>      >>>   So, no big deal, just unexpected.
>      >>      >>>
>      >>      >>>   If we're blaming this on the distro, that really
>      suprises
>      >>        me since you're
>      >>      >>>   basically saying that there are either very few
>      ThinStation
>      >>        users who are
>      >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>      other TS
>      >>        users who do
>      >>      >>>   use
>      >>      >>>   the same distro as me are just suffering in
>      silence. 
>      >>        Maybe, who knows.
>      >>      >>>   I'd also find it hard to believe this is distro
>      related
>      >>        given that
>      >>      >>>   setup-chroot is just bash code, and not terribly
>      complex
>      >>        bash code at
>      >>      >>>   that.  I'm curious now though: on what distro(s)
>      does this
>      >>        all work
>      >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>      to ease
>      >>        my pain.
>      >>      >>>
>      >>      >>>   Todd
>      >>      >>>
>      >>      >>>
>      >>      >>>   On Mon, 2 May 2022, Don Cupp via
>      Thinstation-general wrote:
>      >>      >>>
>      >>      >>>>   Oh the sadness of the various distro
>      peculiarities. How
>      >>        long does it
>      >>      >>>>   take to try and unmount everything?
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>      Pfaff
>      >>      >>>>   <pf...@rh...> wrote:
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>      2022-04-01.
>      >>      >>>>
>      >>      >>>>   I'm doing builds on a CentOS 7 host.
>      >>      >>>>
>      >>      >>>>   Something with setup-chroot is faulty.  When I
>      exit from
>      >>        setup-chroot,
>      >>      >>>>   it
>      >>      >>>>   does not unmount things like it's supposed to.  I
>      can
>      >>        clearly see the
>      >>      >>>>   code
>      >>      >>>>   in setup-chroot in function do_unmounts() that is
>      supposed
>      >>        to do
>      >>      >>>>   the unmount, and I can see from where this is
>      called, but
>      >>        it's not doing
>      >>      >>>>   its job.
>      >>      >>>>
>      >>      >>>>   This is then somehow leading to various
>      problems.  We've
>      >>        seen both /dev/
>      >>      >>>>   and /dev/pts/ go empty while I've been working
>      with ts6.2
>      >>        recently.
>      >>      >>>>
>      >>      >>>>   Todd
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   _______________________________________________
>      >>      >>>>   Thinstation-general mailing list
>      >>      >>>>   Thi...@li...
>      >>      >>>>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>
>      >>      >>>
>      >>      >>>>
>      >>      >>>>
>      >>      >>>>   _______________________________________________
>      >>      >>>>   Thinstation-general mailing list
>      >>      >>>>   Thi...@li...
>      >>      >>>>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>>>
>      >>      >>
>      >>      >>   _______________________________________________
>      >>      >>   Thinstation-general mailing list
>      >>      >>   Thi...@li...
>      >>      >>  
>      >>       
>      https://lists.sourceforge.net/lists/listinfo/thinstation-general
>      >>      >>
>      >>      >>
>      >>      >
>      >>      >
>      >>
>      >>
>      >>
>      >
>      >
> 
> 
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

Sorry, I just realized that I'd been using the wrong thread for this 
subject matter today.

I've changed my NET_ entries in build to conf to NET_IPV4 equivalents 
based on what I could find in various files under build/.  This is what I 
now have in thinstation.conf.buildtime:

NET_USE=LAN
NET_USE_DHCP=off
NET_HOSTNAME=tc1
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS1=8.8.8.8
NET_IPV4_DNS_SEARCH=mydomain.com


I then did a new build and then wrote my usb drive with:

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/grub/efi-source \
/dev/sdh


Boot fails in the same way as before, with the network unconfigured.

I tried again but with fastboot=false.

Same thing.  No network configuration.

I then tried adding the NET_ settings to the kernel cmdline in grub.cfg?.
That is, I mounted sdh1 on /tmp/mnt, edited /tmp/mnt/boot/grub/grub.cfg 
to look like this:

menuentry 'ThinStation' --class thinstation --class gnu-linux --class gnu 
--class os --unrestricted {
         set enable_progress_indicator=1
         linux /boot/vmlinuz  splash=verbose,theme:default  LM=$LM 
NET_IPV4_MODE=manual
NET_IPV4_ADDRESS=192.168.1.2/24 
NET_IPV4_GATEWAY=192.168.1.1
NET_IPV4_DNS="1.1.1.1;2.2.2.2"
NET_IPV4_DNS_SEARCH="mydomain.com"
         initrd /boot/initrd
}


All those NET_ entries follow the LM=$LM on the same line, it's just split 
in this email.

Booted again, kernel loads, initrd loads, and sometime later it fails
in the same way, with no network configuration.

What could I possible be doing wrong now?


Btw, what does this syntax mean?

NET_HOSTNAME=tc_*


Thanks,
Todd


On Wed, 4 May 2022, Don Cupp wrote:

> Yep, your getting used to my organization already :)
> 
> 
> Sent from Yahoo Mail for iPhone
> 
> On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...>
> wrote:
>
>       I assume I should look here for details, yes?
>
>       [root@TS_chroot]/build# less
>       packages/autonet/etc/udev/scripts/net.sh
> 
>
>       or, if I were using the networkmanager package, look hereabouts?
>
>       ./packages/networkmanager/build/conf/64networkmanager
> 
> 
>
>       On Wed, 4 May 2022, Todd Pfaff wrote:
>
>       > omg.  I wish I'd asked earlier.  So sad for time wasted.
>       >
>       > I find plenty of old references to NET_(!IPV4)_stuff that I
>       was following. I
>       > have not yet come across a single googlematch that lead me in
>       the
>       > NET_IPV4_stuff direction.  But now that I grep for NET_IPV
>       under build/, I
>       > see.
>       >
>       > Anyway, thanks, better late than never. :)
>       >
>       >
>       > On Wed, 4 May 2022, Don Cupp wrote:
>       >
>       >>  I think it changed to NET_IPV4 prefix a few years back.
>       Where did you get
>       >>  that code? I’ll update it.
>       >>
>       >>  Sent from Yahoo Mail for iPhone
>       >>
>       >>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff
>       <pf...@rh...>
>       >>  wrote:
>       >>
>       >>        I first tried this (my usb drive is sdh):
>       >>
>       >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>       >>        /build/boot-images/systemd-boot-iso/efi-source
>       /dev/sdh
>       >>
>       >>
>       >>        I then plugged that usb drive to my thinstation
>       machine and
>       >>        booted.  I had
>       >>        to add the uefi boot entry manually - it wasn't
>       autodetected -
>       >>        not sure if
>       >>        that is "normal".  Booting started but failed, I
>       think, because
>       >>        my network
>       >>        wasn't configured.  I'm aiming for a static network
>       >>        configuration in this
>       >>        case.
>       >>
>       >>        I next tried with refind:
>       >>
>       >>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>       >>        /build/boot-images/refind-iso/efi-source /dev/sdh
>       >>
>       >>
>       >>        Same dance, same failure mode - no network
>       configuration.
>       >>
>       >>
>       >>        I have this in my thinstation.conf.buildtime:
>       >>
>       >>        NET_HOSTNAME=tc003
>       >>        NET_IP_ADDRESS=192.168.1.2
>       >>        NET_GATEWAY=192.168.1.1
>       >>        NET_USE=LAN
>       >>        NET_USE_DHCP=false
>       >>        NET_MASK=255.255.255.0
>       >>        NET_DNS_SEARCH="mydomain.com"
>       >>        NET_DNS1=8.8.8.8
>       >>
>       >>
>       >>        What am I missing?  Is there anything else I need to
>       add to
>       >>        either
>       >>        build.conf or thinstation.conf.buildtime to be able to
>       efi boot
>       >>        from a usb
>       >>        drive with a static network configuration?
>       >>
>       >>        Thanks,
>       >>        Todd
>       >>
>       >>
>       >>        On Wed, 4 May 2022, Todd Pfaff wrote:
>       >>
>       >>      >  This is all very interesting.  I looked at bt, and
>       flash, and
>       >>        mkgptdrv. Lots
>       >>      >  of archaeological excavation to do.
>       >>      >
>       >>      >  What is the current recommended way to write a UEFI
>       bootable
>       >>        USB drive from a
>       >>      >  command line in the chroot environment?  I don't want
>       to
>       >>        bother with
>       >>      >  Windows+rufus is I can possibly avoid that.
>       >>      >
>       >>      >  My guess is that I could either use your
>       /ts/bin/flash script,
>       >>        or I could use
>       >>      >  a command line similar to what I see in flash, using
>       mkgptdrv
>       >>        or mkmbrdrv.
>       >>      >  Correct?
>       >>      >
>       >>      >  In this particular case, since I need to UEFI boot, I
>       think I
>       >>        need mkgptdrv
>       >>      >  rather than mkmbrdrv.  Correct?
>       >>      >
>       >>      >  So, looking at your flash script, you have this entry
>       that
>       >>        uses mkgptdrv:
>       >>      >
>       >>      > systemd)
>       >>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>       >>      >  /build/boot-images/systemd-boot-iso/efi-source
>       /dev/sdb
>       >>      >
>       >>      >
>       >>      >  which leads me to believe that I'll need
>       >>        boot-images/systemd-boot-iso, and
>       >>      >  based on what I see in the build script, this means
>       that I
>       >>        have to add
>       >>      >  systemd-boot-iso to param bootimages in build.conf. 
>       Correct?
>       >>      >
>       >>      >  In general, do you recommend just leaving param
>       bootimages
>       >>        empty so that the
>       >>      >  build script sets it to it's default as it does with
>       this
>       >>        code?
>       >>      >
>       >>      > if [ -z "$ts_bootimages" ]; then
>       >>      >         ts_bootimages="syslinux iso pxe refind-iso
>       >>        systemd-boot-iso grub"
>       >>      >
>       >>      >
>       >>      >  Is "systemd-boot-iso" the best option to use for my
>       use case
>       >>        of a UEFI
>       >>      >  bootable USB drive, or is there something else I
>       should
>       >>        consider that's
>       >>      >  already baked into the TS6.2 pie (and hopefully won't
>       require
>       >>        me to make too
>       >>      >  many more educated guesses :).
>       >>      >
>       >>      >  Thanks,
>       >>      >  Todd
>       >>      >
>       >>      >
>       >>      >  On Tue, 3 May 2022, Don Cupp wrote:
>       >>      >
>       >>      >>   You can also open the file /ts/bin/bt in a text
>       editor and
>       >>        look at the
>       >>      >>   code I use for doing different things.
>       >>      >>
>       >>      >>   Have a look at
>       >>      >>
>       >>      >>   wrap_grub_efi() for some clues.
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>       >>        <don...@ya...>
>       >>      >>   wrote:
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>   After doing a build, try 
>       >>      >>   bt net or bt net-efi
>       >>      >>   to test a pxe boot and possibly an install
>       >>      >>   afterwards,
>       >>      >>   bt image-grub to test your install
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp
>       via
>       >>        Thinstation-general
>       >>      >>   <thi...@li...> wrote:
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>
>       >>      >>   I use fedora. It’s not the code, just how the
>       distro is
>       >>        handling umount.
>       >>      >>   You can see me calling it. On Ubuntu, if I don’t
>       use lazy
>       >>        umount, it hangs
>       >>      >>   the exit.
>       >>      >>
>       >>      >>
>       >>      >>   Sent from Yahoo Mail for iPhone
>       >>      >>
>       >>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>       >>        <pf...@rh...>
>       >>      >>   wrote:
>       >>      >>>   It's trivial.  I just run the following command
>       several
>       >>        times after I
>       >>      >>>   exit
>       >>      >>>   the setup-chroot shell.  It has become as quick as
>       a !for
>       >>        in my build
>       >>      >>>   shell.
>       >>      >>>
>       >>      >>>   for f in `mount|grep thinstation | awk '{print
>       $3}'`; do
>       >>        echo $f; umount
>       >>      >>>   $f; done
>       >>      >>>
>       >>      >>>
>       >>      >>>   So, no big deal, just unexpected.
>       >>      >>>
>       >>      >>>   If we're blaming this on the distro, that really
>       suprises
>       >>        me since you're
>       >>      >>>   basically saying that there are either very few
>       ThinStation
>       >>        users who are
>       >>      >>>   building on a RHEL/CentOS 7 platform, or all the
>       other TS
>       >>        users who do
>       >>      >>>   use
>       >>      >>>   the same distro as me are just suffering in
>       silence. 
>       >>        Maybe, who knows.
>       >>      >>>   I'd also find it hard to believe this is distro
>       related
>       >>        given that
>       >>      >>>   setup-chroot is just bash code, and not terribly
>       complex
>       >>        bash code at
>       >>      >>>   that.  I'm curious now though: on what distro(s)
>       does this
>       >>        all work
>       >>      >>>   flawlessly?  Maybe I'll spin one of those up just
>       to ease
>       >>        my pain.
>       >>      >>>
>       >>      >>>   Todd
>       >>      >>>
>       >>      >>>
>       >>      >>>   On Mon, 2 May 2022, Don Cupp via
>       Thinstation-general wrote:
>       >>      >>>
>       >>      >>>>   Oh the sadness of the various distro
>       peculiarities. How
>       >>        long does it
>       >>      >>>>   take to try and unmount everything?
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd
>       Pfaff
>       >>      >>>>   <pf...@rh...> wrote:
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>   I'm using thinstation 6.2-Stable, git cloned
>       2022-04-01.
>       >>      >>>>
>       >>      >>>>   I'm doing builds on a CentOS 7 host.
>       >>      >>>>
>       >>      >>>>   Something with setup-chroot is faulty.  When I
>       exit from
>       >>        setup-chroot,
>       >>      >>>>   it
>       >>      >>>>   does not unmount things like it's supposed to.  I
>       can
>       >>        clearly see the
>       >>      >>>>   code
>       >>      >>>>   in setup-chroot in function do_unmounts() that is
>       supposed
>       >>        to do
>       >>      >>>>   the unmount, and I can see from where this is
>       called, but
>       >>        it's not doing
>       >>      >>>>   its job.
>       >>      >>>>
>       >>      >>>>   This is then somehow leading to various
>       problems.  We've
>       >>        seen both /dev/
>       >>      >>>>   and /dev/pts/ go empty while I've been working
>       with ts6.2
>       >>        recently.
>       >>      >>>>
>       >>      >>>>   Todd
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>   _______________________________________________
>       >>      >>>>   Thinstation-general mailing list
>       >>      >>>>   Thi...@li...
>       >>      >>>>  
>       >>       
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >>      >>
>       >>      >>>
>       >>      >>>>
>       >>      >>>>
>       >>      >>>>   _______________________________________________
>       >>      >>>>   Thinstation-general mailing list
>       >>      >>>>   Thi...@li...
>       >>      >>>>  
>       >>       
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >>      >>>>
>       >>      >>
>       >>      >>   _______________________________________________
>       >>      >>   Thinstation-general mailing list
>       >>      >>   Thi...@li...
>       >>      >>  
>       >>       
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >>      >>
>       >>      >>
>       >>      >
>       >>      >
>       >>
>       >>
>       >>
>       >
>       >
> 
> 
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Don C. <don...@ya...>]

Yep, your getting used to my organization already :)


Sent from Yahoo Mail for iPhone


On Wednesday, May 4, 2022, 11:59 AM, Todd Pfaff <pf...@rh...> wrote:

I assume I should look here for details, yes?

[root@TS_chroot]/build# less packages/autonet/etc/udev/scripts/net.sh


or, if I were using the networkmanager package, look hereabouts?

./packages/networkmanager/build/conf/64networkmanager



On Wed, 4 May 2022, Todd Pfaff wrote:

> omg.  I wish I'd asked earlier.  So sad for time wasted.
>
> I find plenty of old references to NET_(!IPV4)_stuff that I was following. I 
> have not yet come across a single googlematch that lead me in the 
> NET_IPV4_stuff direction.  But now that I grep for NET_IPV under build/, I 
> see.
>
> Anyway, thanks, better late than never. :)
>
>
> On Wed, 4 May 2022, Don Cupp wrote:
>
>>  I think it changed to NET_IPV4 prefix a few years back. Where did you get
>>  that code? I’ll update it.
>>
>>  Sent from Yahoo Mail for iPhone
>>
>>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff <pf...@rh...>
>>  wrote:
>>
>>        I first tried this (my usb drive is sdh):
>>
>>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>        /build/boot-images/systemd-boot-iso/efi-source /dev/sdh
>> 
>>
>>        I then plugged that usb drive to my thinstation machine and
>>        booted.  I had
>>        to add the uefi boot entry manually - it wasn't autodetected -
>>        not sure if
>>        that is "normal".  Booting started but failed, I think, because
>>        my network
>>        wasn't configured.  I'm aiming for a static network
>>        configuration in this
>>        case.
>>
>>        I next tried with refind:
>>
>>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>        /build/boot-images/refind-iso/efi-source /dev/sdh
>> 
>>
>>        Same dance, same failure mode - no network configuration.
>> 
>>
>>        I have this in my thinstation.conf.buildtime:
>>
>>        NET_HOSTNAME=tc003
>>        NET_IP_ADDRESS=192.168.1.2
>>        NET_GATEWAY=192.168.1.1
>>        NET_USE=LAN
>>        NET_USE_DHCP=false
>>        NET_MASK=255.255.255.0
>>        NET_DNS_SEARCH="mydomain.com"
>>        NET_DNS1=8.8.8.8
>> 
>>
>>        What am I missing?  Is there anything else I need to add to
>>        either
>>        build.conf or thinstation.conf.buildtime to be able to efi boot
>>        from a usb
>>        drive with a static network configuration?
>>
>>        Thanks,
>>        Todd
>> 
>>
>>        On Wed, 4 May 2022, Todd Pfaff wrote:
>>
>>      >  This is all very interesting.  I looked at bt, and flash, and
>>        mkgptdrv. Lots
>>      >  of archaeological excavation to do.
>>      >
>>      >  What is the current recommended way to write a UEFI bootable
>>        USB drive from a
>>      >  command line in the chroot environment?  I don't want to
>>        bother with
>>      >  Windows+rufus is I can possibly avoid that.
>>      >
>>      >  My guess is that I could either use your /ts/bin/flash script,
>>        or I could use
>>      >  a command line similar to what I see in flash, using mkgptdrv
>>        or mkmbrdrv.
>>      >  Correct?
>>      >
>>      >  In this particular case, since I need to UEFI boot, I think I
>>        need mkgptdrv
>>      >  rather than mkmbrdrv.  Correct?
>>      >
>>      >  So, looking at your flash script, you have this entry that
>>        uses mkgptdrv:
>>      >
>>      > systemd)
>>      >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>>      >  /build/boot-images/systemd-boot-iso/efi-source /dev/sdb
>>      >
>>      >
>>      >  which leads me to believe that I'll need
>>        boot-images/systemd-boot-iso, and
>>      >  based on what I see in the build script, this means that I
>>        have to add
>>      >  systemd-boot-iso to param bootimages in build.conf.  Correct?
>>      >
>>      >  In general, do you recommend just leaving param bootimages
>>        empty so that the
>>      >  build script sets it to it's default as it does with this
>>        code?
>>      >
>>      > if [ -z "$ts_bootimages" ]; then
>>      >         ts_bootimages="syslinux iso pxe refind-iso
>>        systemd-boot-iso grub"
>>      >
>>      >
>>      >  Is "systemd-boot-iso" the best option to use for my use case
>>        of a UEFI
>>      >  bootable USB drive, or is there something else I should
>>        consider that's
>>      >  already baked into the TS6.2 pie (and hopefully won't require
>>        me to make too
>>      >  many more educated guesses :).
>>      >
>>      >  Thanks,
>>      >  Todd
>>      >
>>      >
>>      >  On Tue, 3 May 2022, Don Cupp wrote:
>>      >
>>      >>   You can also open the file /ts/bin/bt in a text editor and
>>        look at the
>>      >>   code I use for doing different things.
>>      >>
>>      >>   Have a look at
>>      >>
>>      >>   wrap_grub_efi() for some clues.
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>>        <don...@ya...>
>>      >>   wrote:
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>   After doing a build, try 
>>      >>   bt net or bt net-efi
>>      >>   to test a pxe boot and possibly an install
>>      >>   afterwards,
>>      >>   bt image-grub to test your install
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via
>>        Thinstation-general
>>      >>   <thi...@li...> wrote:
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>
>>      >>   I use fedora. It’s not the code, just how the distro is
>>        handling umount.
>>      >>   You can see me calling it. On Ubuntu, if I don’t use lazy
>>        umount, it hangs
>>      >>   the exit.
>>      >>
>>      >>
>>      >>   Sent from Yahoo Mail for iPhone
>>      >>
>>      >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>>        <pf...@rh...>
>>      >>   wrote:
>>      >>>   It's trivial.  I just run the following command several
>>        times after I
>>      >>>   exit
>>      >>>   the setup-chroot shell.  It has become as quick as a !for
>>        in my build
>>      >>>   shell.
>>      >>>
>>      >>>   for f in `mount|grep thinstation | awk '{print $3}'`; do
>>        echo $f; umount
>>      >>>   $f; done
>>      >>>
>>      >>>
>>      >>>   So, no big deal, just unexpected.
>>      >>>
>>      >>>   If we're blaming this on the distro, that really suprises
>>        me since you're
>>      >>>   basically saying that there are either very few ThinStation
>>        users who are
>>      >>>   building on a RHEL/CentOS 7 platform, or all the other TS
>>        users who do
>>      >>>   use
>>      >>>   the same distro as me are just suffering in silence. 
>>        Maybe, who knows.
>>      >>>   I'd also find it hard to believe this is distro related
>>        given that
>>      >>>   setup-chroot is just bash code, and not terribly complex
>>        bash code at
>>      >>>   that.  I'm curious now though: on what distro(s) does this
>>        all work
>>      >>>   flawlessly?  Maybe I'll spin one of those up just to ease
>>        my pain.
>>      >>>
>>      >>>   Todd
>>      >>>
>>      >>>
>>      >>>   On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>>      >>>
>>      >>>>   Oh the sadness of the various distro peculiarities. How
>>        long does it
>>      >>>>   take to try and unmount everything?
>>      >>>>
>>      >>>>
>>      >>>>
>>      >>>>
>>      >>>>
>>      >>>>
>>      >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff
>>      >>>>   <pf...@rh...> wrote:
>>      >>>>
>>      >>>>
>>      >>>>
>>      >>>>
>>      >>>>
>>      >>>>   I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>>      >>>>
>>      >>>>   I'm doing builds on a CentOS 7 host.
>>      >>>>
>>      >>>>   Something with setup-chroot is faulty.  When I exit from
>>        setup-chroot,
>>      >>>>   it
>>      >>>>   does not unmount things like it's supposed to.  I can
>>        clearly see the
>>      >>>>   code
>>      >>>>   in setup-chroot in function do_unmounts() that is supposed
>>        to do
>>      >>>>   the unmount, and I can see from where this is called, but
>>        it's not doing
>>      >>>>   its job.
>>      >>>>
>>      >>>>   This is then somehow leading to various problems.  We've
>>        seen both /dev/
>>      >>>>   and /dev/pts/ go empty while I've been working with ts6.2
>>        recently.
>>      >>>>
>>      >>>>   Todd
>>      >>>>
>>      >>>>
>>      >>>>   _______________________________________________
>>      >>>>   Thinstation-general mailing list
>>      >>>>   Thi...@li...
>>      >>>>  
>>        https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>
>>      >>>
>>      >>>>
>>      >>>>
>>      >>>>   _______________________________________________
>>      >>>>   Thinstation-general mailing list
>>      >>>>   Thi...@li...
>>      >>>>  
>>        https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>>>
>>      >>
>>      >>   _______________________________________________
>>      >>   Thinstation-general mailing list
>>      >>   Thi...@li...
>>      >>  
>>        https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>      >>
>>      >>
>>      >
>>      >
>>
>> 
>> 
>
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

I assume I should look here for details, yes?

[root@TS_chroot]/build# less packages/autonet/etc/udev/scripts/net.sh


or, if I were using the networkmanager package, look hereabouts?

./packages/networkmanager/build/conf/64networkmanager



On Wed, 4 May 2022, Todd Pfaff wrote:

> omg.  I wish I'd asked earlier.  So sad for time wasted.
>
> I find plenty of old references to NET_(!IPV4)_stuff that I was following. I 
> have not yet come across a single googlematch that lead me in the 
> NET_IPV4_stuff direction.  But now that I grep for NET_IPV under build/, I 
> see.
>
> Anyway, thanks, better late than never. :)
>
>
> On Wed, 4 May 2022, Don Cupp wrote:
>
>>  I think it changed to NET_IPV4 prefix a few years back. Where did you get
>>  that code? I’ll update it.
>>
>>  Sent from Yahoo Mail for iPhone
>>
>>  On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff <pf...@rh...>
>>  wrote:
>>
>>        I first tried this (my usb drive is sdh):
>>
>>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>        /build/boot-images/systemd-boot-iso/efi-source /dev/sdh
>> 
>>
>>        I then plugged that usb drive to my thinstation machine and
>>        booted.  I had
>>        to add the uefi boot entry manually - it wasn't autodetected -
>>        not sure if
>>        that is "normal".  Booting started but failed, I think, because
>>        my network
>>        wasn't configured.  I'm aiming for a static network
>>        configuration in this
>>        case.
>>
>>        I next tried with refind:
>>
>>        mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>>        /build/boot-images/refind-iso/efi-source /dev/sdh
>> 
>>
>>        Same dance, same failure mode - no network configuration.
>> 
>>
>>        I have this in my thinstation.conf.buildtime:
>>
>>        NET_HOSTNAME=tc003
>>        NET_IP_ADDRESS=192.168.1.2
>>        NET_GATEWAY=192.168.1.1
>>        NET_USE=LAN
>>        NET_USE_DHCP=false
>>        NET_MASK=255.255.255.0
>>        NET_DNS_SEARCH="mydomain.com"
>>        NET_DNS1=8.8.8.8
>> 
>>
>>        What am I missing?  Is there anything else I need to add to
>>        either
>>        build.conf or thinstation.conf.buildtime to be able to efi boot
>>        from a usb
>>        drive with a static network configuration?
>>
>>        Thanks,
>>        Todd
>> 
>>
>>        On Wed, 4 May 2022, Todd Pfaff wrote:
>>
>>       >  This is all very interesting.  I looked at bt, and flash, and
>>        mkgptdrv. Lots
>>       >  of archaeological excavation to do.
>>       >
>>       >  What is the current recommended way to write a UEFI bootable
>>        USB drive from a
>>       >  command line in the chroot environment?  I don't want to
>>        bother with
>>       >  Windows+rufus is I can possibly avoid that.
>>       >
>>       >  My guess is that I could either use your /ts/bin/flash script,
>>        or I could use
>>       >  a command line similar to what I see in flash, using mkgptdrv
>>        or mkmbrdrv.
>>       >  Correct?
>>       >
>>       >  In this particular case, since I need to UEFI boot, I think I
>>        need mkgptdrv
>>       >  rather than mkmbrdrv.  Correct?
>>       >
>>       >  So, looking at your flash script, you have this entry that
>>        uses mkgptdrv:
>>       >
>>       > systemd)
>>       >         mkgptdrv -p ESP:2g:boot -p l:0:home -o
>>       >  /build/boot-images/systemd-boot-iso/efi-source /dev/sdb
>>       >
>>       >
>>       >  which leads me to believe that I'll need
>>        boot-images/systemd-boot-iso, and
>>       >  based on what I see in the build script, this means that I
>>        have to add
>>       >  systemd-boot-iso to param bootimages in build.conf.  Correct?
>>       >
>>       >  In general, do you recommend just leaving param bootimages
>>        empty so that the
>>       >  build script sets it to it's default as it does with this
>>        code?
>>       >
>>       > if [ -z "$ts_bootimages" ]; then
>>       >         ts_bootimages="syslinux iso pxe refind-iso
>>        systemd-boot-iso grub"
>>       >
>>       >
>>       >  Is "systemd-boot-iso" the best option to use for my use case
>>        of a UEFI
>>       >  bootable USB drive, or is there something else I should
>>        consider that's
>>       >  already baked into the TS6.2 pie (and hopefully won't require
>>        me to make too
>>       >  many more educated guesses :).
>>       >
>>       >  Thanks,
>>       >  Todd
>>       >
>>       >
>>       >  On Tue, 3 May 2022, Don Cupp wrote:
>>       >
>>       >>   You can also open the file /ts/bin/bt in a text editor and
>>        look at the
>>       >>   code I use for doing different things.
>>       >>
>>       >>   Have a look at
>>       >>
>>       >>   wrap_grub_efi() for some clues.
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>   On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>>        <don...@ya...>
>>       >>   wrote:
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>   After doing a build, try 
>>       >>   bt net or bt net-efi
>>       >>   to test a pxe boot and possibly an install
>>       >>   afterwards,
>>       >>   bt image-grub to test your install
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>   On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via
>>        Thinstation-general
>>       >>   <thi...@li...> wrote:
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>
>>       >>   I use fedora. It’s not the code, just how the distro is
>>        handling umount.
>>       >>   You can see me calling it. On Ubuntu, if I don’t use lazy
>>        umount, it hangs
>>       >>   the exit.
>>       >>
>>       >>
>>       >>   Sent from Yahoo Mail for iPhone
>>       >>
>>       >>   On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>>        <pf...@rh...>
>>       >>   wrote:
>>       >>>   It's trivial.  I just run the following command several
>>        times after I
>>       >>>   exit
>>       >>>   the setup-chroot shell.  It has become as quick as a !for
>>        in my build
>>       >>>   shell.
>>       >>>
>>       >>>   for f in `mount|grep thinstation | awk '{print $3}'`; do
>>        echo $f; umount
>>       >>>   $f; done
>>       >>>
>>       >>>
>>       >>>   So, no big deal, just unexpected.
>>       >>>
>>       >>>   If we're blaming this on the distro, that really suprises
>>        me since you're
>>       >>>   basically saying that there are either very few ThinStation
>>        users who are
>>       >>>   building on a RHEL/CentOS 7 platform, or all the other TS
>>        users who do
>>       >>>   use
>>       >>>   the same distro as me are just suffering in silence. 
>>        Maybe, who knows.
>>       >>>   I'd also find it hard to believe this is distro related
>>        given that
>>       >>>   setup-chroot is just bash code, and not terribly complex
>>        bash code at
>>       >>>   that.  I'm curious now though: on what distro(s) does this
>>        all work
>>       >>>   flawlessly?  Maybe I'll spin one of those up just to ease
>>        my pain.
>>       >>>
>>       >>>   Todd
>>       >>>
>>       >>>
>>       >>>   On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>>       >>>
>>       >>>>   Oh the sadness of the various distro peculiarities. How
>>        long does it
>>       >>>>   take to try and unmount everything?
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>   On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff
>>       >>>>   <pf...@rh...> wrote:
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>
>>       >>>>   I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>>       >>>>
>>       >>>>   I'm doing builds on a CentOS 7 host.
>>       >>>>
>>       >>>>   Something with setup-chroot is faulty.  When I exit from
>>        setup-chroot,
>>       >>>>   it
>>       >>>>   does not unmount things like it's supposed to.  I can
>>        clearly see the
>>       >>>>   code
>>       >>>>   in setup-chroot in function do_unmounts() that is supposed
>>        to do
>>       >>>>   the unmount, and I can see from where this is called, but
>>        it's not doing
>>       >>>>   its job.
>>       >>>>
>>       >>>>   This is then somehow leading to various problems.  We've
>>        seen both /dev/
>>       >>>>   and /dev/pts/ go empty while I've been working with ts6.2
>>        recently.
>>       >>>>
>>       >>>>   Todd
>>       >>>>
>>       >>>>
>>       >>>>   _______________________________________________
>>       >>>>   Thinstation-general mailing list
>>       >>>>   Thi...@li...
>>       >>>>  
>>        https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>       >>
>>       >>>
>>       >>>>
>>       >>>>
>>       >>>>   _______________________________________________
>>       >>>>   Thinstation-general mailing list
>>       >>>>   Thi...@li...
>>       >>>>  
>>        https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>       >>>>
>>       >>
>>       >>   _______________________________________________
>>       >>   Thinstation-general mailing list
>>       >>   Thi...@li...
>>       >>  
>>        https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>       >>
>>       >>
>>       >
>>       >
>>
>> 
>> 
>
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

omg.  I wish I'd asked earlier.  So sad for time wasted.

I find plenty of old references to NET_(!IPV4)_stuff that I was following. 
I have not yet come across a single googlematch that lead me in the 
NET_IPV4_stuff direction.  But now that I grep for NET_IPV under build/, I 
see.

Anyway, thanks, better late than never. :)


On Wed, 4 May 2022, Don Cupp wrote:

> I think it changed to NET_IPV4 prefix a few years back. Where did you get
> that code? I’ll update it.
> 
> Sent from Yahoo Mail for iPhone
> 
> On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff <pf...@rh...>
> wrote:
>
>       I first tried this (my usb drive is sdh):
>
>       mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>       /build/boot-images/systemd-boot-iso/efi-source /dev/sdh
> 
>
>       I then plugged that usb drive to my thinstation machine and
>       booted.  I had
>       to add the uefi boot entry manually - it wasn't autodetected -
>       not sure if
>       that is "normal".  Booting started but failed, I think, because
>       my network
>       wasn't configured.  I'm aiming for a static network
>       configuration in this
>       case.
>
>       I next tried with refind:
>
>       mkgptdrv -p ESP:2g:boot -p l:0:home -o \
>       /build/boot-images/refind-iso/efi-source /dev/sdh
> 
>
>       Same dance, same failure mode - no network configuration.
> 
>
>       I have this in my thinstation.conf.buildtime:
>
>       NET_HOSTNAME=tc003
>       NET_IP_ADDRESS=192.168.1.2
>       NET_GATEWAY=192.168.1.1
>       NET_USE=LAN
>       NET_USE_DHCP=false
>       NET_MASK=255.255.255.0
>       NET_DNS_SEARCH="mydomain.com"
>       NET_DNS1=8.8.8.8
> 
>
>       What am I missing?  Is there anything else I need to add to
>       either
>       build.conf or thinstation.conf.buildtime to be able to efi boot
>       from a usb
>       drive with a static network configuration?
>
>       Thanks,
>       Todd
> 
>
>       On Wed, 4 May 2022, Todd Pfaff wrote:
>
>       > This is all very interesting.  I looked at bt, and flash, and
>       mkgptdrv. Lots
>       > of archaeological excavation to do.
>       >
>       > What is the current recommended way to write a UEFI bootable
>       USB drive from a
>       > command line in the chroot environment?  I don't want to
>       bother with
>       > Windows+rufus is I can possibly avoid that.
>       >
>       > My guess is that I could either use your /ts/bin/flash script,
>       or I could use
>       > a command line similar to what I see in flash, using mkgptdrv
>       or mkmbrdrv.
>       > Correct?
>       >
>       > In this particular case, since I need to UEFI boot, I think I
>       need mkgptdrv
>       > rather than mkmbrdrv.  Correct?
>       >
>       > So, looking at your flash script, you have this entry that
>       uses mkgptdrv:
>       >
>       > systemd)
>       >        mkgptdrv -p ESP:2g:boot -p l:0:home -o
>       > /build/boot-images/systemd-boot-iso/efi-source /dev/sdb
>       >
>       >
>       > which leads me to believe that I'll need
>       boot-images/systemd-boot-iso, and
>       > based on what I see in the build script, this means that I
>       have to add
>       > systemd-boot-iso to param bootimages in build.conf.  Correct?
>       >
>       > In general, do you recommend just leaving param bootimages
>       empty so that the
>       > build script sets it to it's default as it does with this
>       code?
>       >
>       > if [ -z "$ts_bootimages" ]; then
>       >        ts_bootimages="syslinux iso pxe refind-iso
>       systemd-boot-iso grub"
>       >
>       >
>       > Is "systemd-boot-iso" the best option to use for my use case
>       of a UEFI
>       > bootable USB drive, or is there something else I should
>       consider that's
>       > already baked into the TS6.2 pie (and hopefully won't require
>       me to make too
>       > many more educated guesses :).
>       >
>       > Thanks,
>       > Todd
>       >
>       >
>       > On Tue, 3 May 2022, Don Cupp wrote:
>       >
>       >>  You can also open the file /ts/bin/bt in a text editor and
>       look at the
>       >>  code I use for doing different things.
>       >>
>       >>  Have a look at
>       >>
>       >>  wrap_grub_efi() for some clues.
>       >>
>       >>
>       >>
>       >>
>       >>
>       >>
>       >>  On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>       <don...@ya...>
>       >>  wrote:
>       >>
>       >>
>       >>
>       >>
>       >>
>       >>  After doing a build, try 
>       >>  bt net or bt net-efi
>       >>  to test a pxe boot and possibly an install
>       >>  afterwards,
>       >>  bt image-grub to test your install
>       >>
>       >>
>       >>
>       >>
>       >>
>       >>
>       >>  On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via
>       Thinstation-general
>       >>  <thi...@li...> wrote:
>       >>
>       >>
>       >>
>       >>
>       >>
>       >>  I use fedora. It’s not the code, just how the distro is
>       handling umount.
>       >>  You can see me calling it. On Ubuntu, if I don’t use lazy
>       umount, it hangs
>       >>  the exit.
>       >>
>       >>
>       >>  Sent from Yahoo Mail for iPhone
>       >>
>       >>  On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>       <pf...@rh...>
>       >>  wrote:
>       >>>  It's trivial.  I just run the following command several
>       times after I
>       >>>  exit
>       >>>  the setup-chroot shell.  It has become as quick as a !for
>       in my build
>       >>>  shell.
>       >>>
>       >>>  for f in `mount|grep thinstation | awk '{print $3}'`; do
>       echo $f; umount
>       >>>  $f; done
>       >>>
>       >>>
>       >>>  So, no big deal, just unexpected.
>       >>>
>       >>>  If we're blaming this on the distro, that really suprises
>       me since you're
>       >>>  basically saying that there are either very few ThinStation
>       users who are
>       >>>  building on a RHEL/CentOS 7 platform, or all the other TS
>       users who do
>       >>>  use
>       >>>  the same distro as me are just suffering in silence. 
>       Maybe, who knows.
>       >>>  I'd also find it hard to believe this is distro related
>       given that
>       >>>  setup-chroot is just bash code, and not terribly complex
>       bash code at
>       >>>  that.  I'm curious now though: on what distro(s) does this
>       all work
>       >>>  flawlessly?  Maybe I'll spin one of those up just to ease
>       my pain.
>       >>>
>       >>>  Todd
>       >>>
>       >>>
>       >>>  On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>       >>>
>       >>>>  Oh the sadness of the various distro peculiarities. How
>       long does it
>       >>>>  take to try and unmount everything?
>       >>>>
>       >>>>
>       >>>>
>       >>>>
>       >>>>
>       >>>>
>       >>>>  On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff
>       >>>>  <pf...@rh...> wrote:
>       >>>>
>       >>>>
>       >>>>
>       >>>>
>       >>>>
>       >>>>  I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>       >>>>
>       >>>>  I'm doing builds on a CentOS 7 host.
>       >>>>
>       >>>>  Something with setup-chroot is faulty.  When I exit from
>       setup-chroot,
>       >>>>  it
>       >>>>  does not unmount things like it's supposed to.  I can
>       clearly see the
>       >>>>  code
>       >>>>  in setup-chroot in function do_unmounts() that is supposed
>       to do
>       >>>>  the unmount, and I can see from where this is called, but
>       it's not doing
>       >>>>  its job.
>       >>>>
>       >>>>  This is then somehow leading to various problems.  We've
>       seen both /dev/
>       >>>>  and /dev/pts/ go empty while I've been working with ts6.2
>       recently.
>       >>>>
>       >>>>  Todd
>       >>>>
>       >>>>
>       >>>>  _______________________________________________
>       >>>>  Thinstation-general mailing list
>       >>>>  Thi...@li...
>       >>>> 
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >>
>       >>>
>       >>>>
>       >>>>
>       >>>>  _______________________________________________
>       >>>>  Thinstation-general mailing list
>       >>>>  Thi...@li...
>       >>>> 
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >>>>
>       >>
>       >>  _______________________________________________
>       >>  Thinstation-general mailing list
>       >>  Thi...@li...
>       >> 
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >>
>       >>
>       >
>       >
> 
> 
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

On Wed, 4 May 2022, Don Cupp wrote:

> Glad your digging in.

up to my eyeballs.

> I should update flash to use the grub image, but you could too. 
> 
> /build/boot-images/grub/efi-source
> 
> mkgptdrv is the right utility for EFI

got it, thanks!



> 
> 
> Sent from Yahoo Mail for iPhone
> 
> On Wednesday, May 4, 2022, 10:13 AM, Todd Pfaff <pf...@rh...>
> wrote:
>
>       This is all very interesting.  I looked at bt, and flash, and
>       mkgptdrv.
>       Lots of archaeological excavation to do.
>
>       What is the current recommended way to write a UEFI bootable USB
>       drive
>       from a command line in the chroot environment?  I don't want to
>       bother
>       with Windows+rufus is I can possibly avoid that.
>
>       My guess is that I could either use your /ts/bin/flash script,
>       or I could
>       use a command line similar to what I see in flash, using
>       mkgptdrv or
>       mkmbrdrv.  Correct?
>
>       In this particular case, since I need to UEFI boot, I think I
>       need
>       mkgptdrv rather than mkmbrdrv.  Correct?
>
>       So, looking at your flash script, you have this entry that uses
>       mkgptdrv:
>
>       systemd)
>               mkgptdrv -p ESP:2g:boot -p l:0:home -o
>       /build/boot-images/systemd-boot-iso/efi-source /dev/sdb
> 
>
>       which leads me to believe that I'll need
>       boot-images/systemd-boot-iso,
>       and based on what I see in the build script, this means that I
>       have to add
>       systemd-boot-iso to param bootimages in build.conf.  Correct?
>
>       In general, do you recommend just leaving param bootimages empty
>       so that
>       the build script sets it to it's default as it does with this
>       code?
>
>       if [ -z "$ts_bootimages" ]; then
>               ts_bootimages="syslinux iso pxe refind-iso
>       systemd-boot-iso grub"
> 
>
>       Is "systemd-boot-iso" the best option to use for my use case of
>       a UEFI
>       bootable USB drive, or is there something else I should consider
>       that's
>       already baked into the TS6.2 pie (and hopefully won't require me
>       to make
>       too many more educated guesses :).
>
>       Thanks,
>       Todd
> 
>
>       On Tue, 3 May 2022, Don Cupp wrote:
>
>       > You can also open the file /ts/bin/bt in a text editor and
>       look at the code I use for doing different things.
>       >
>       > Have a look at
>       >
>       > wrap_grub_efi() for some clues.
>       >
>       >
>       >
>       >
>       >
>       >
>       > On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp
>       <don...@ya...> wrote:
>       >
>       >
>       >
>       >
>       >
>       > After doing a build, try 
>       > bt net or bt net-efi
>       > to test a pxe boot and possibly an install
>       > afterwards,
>       > bt image-grub to test your install
>       >
>       >
>       >
>       >
>       >
>       >
>       > On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via
>       Thinstation-general <thi...@li...>
>       wrote:
>       >
>       >
>       >
>       >
>       >
>       > I use fedora. It’s not the code, just how the distro is
>       handling umount. You can see me calling it. On Ubuntu, if I
>       don’t use lazy umount, it hangs the exit.
>       >
>       >
>       > Sent from Yahoo Mail for iPhone
>       >
>       > On Monday, May 2, 2022, 5:21 PM, Todd Pfaff
>       <pf...@rh...> wrote:
>       >> It's trivial.  I just run the following command several times
>       after I exit
>       >> the setup-chroot shell.  It has become as quick as a !for in
>       my build
>       >> shell.
>       >>
>       >> for f in `mount|grep thinstation | awk '{print $3}'`; do echo
>       $f; umount
>       >> $f; done
>       >>
>       >>
>       >> So, no big deal, just unexpected.
>       >>
>       >> If we're blaming this on the distro, that really suprises me
>       since you're
>       >> basically saying that there are either very few ThinStation
>       users who are
>       >> building on a RHEL/CentOS 7 platform, or all the other TS
>       users who do use
>       >> the same distro as me are just suffering in silence.  Maybe,
>       who knows.
>       >> I'd also find it hard to believe this is distro related given
>       that
>       >> setup-chroot is just bash code, and not terribly complex bash
>       code at
>       >> that.  I'm curious now though: on what distro(s) does this
>       all work
>       >> flawlessly?  Maybe I'll spin one of those up just to ease my
>       pain.
>       >>
>       >> Todd
>       >>
>       >>
>       >> On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>       >>
>       >>> Oh the sadness of the various distro peculiarities. How long
>       does it take to try and unmount everything?
>       >>>
>       >>>
>       >>>
>       >>>
>       >>>
>       >>>
>       >>> On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff
>       <pf...@rh...> wrote:
>       >>>
>       >>>
>       >>>
>       >>>
>       >>>
>       >>> I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>       >>>
>       >>> I'm doing builds on a CentOS 7 host.
>       >>>
>       >>> Something with setup-chroot is faulty.  When I exit from
>       setup-chroot, it
>       >>> does not unmount things like it's supposed to.  I can
>       clearly see the code
>       >>> in setup-chroot in function do_unmounts() that is supposed
>       to do
>       >>> the unmount, and I can see from where this is called, but
>       it's not doing
>       >>> its job.
>       >>>
>       >>> This is then somehow leading to various problems.  We've
>       seen both /dev/
>       >>> and /dev/pts/ go empty while I've been working with ts6.2
>       recently.
>       >>>
>       >>> Todd
>       >>>
>       >>>
>       >>> _______________________________________________
>       >>> Thinstation-general mailing list
>       >>> Thi...@li...
>       >>>
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >
>       >>
>       >>>
>       >>>
>       >>> _______________________________________________
>       >>> Thinstation-general mailing list
>       >>> Thi...@li...
>       >>>
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >>>
>       >
>       > _______________________________________________
>       > Thinstation-general mailing list
>       > Thi...@li...
>       >
>       https://lists.sourceforge.net/lists/listinfo/thinstation-general
>       >
>       >
> 
> 
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Don C. <don...@ya...>]

I think it changed to NET_IPV4 prefix a few years back. Where did you get that code? I’ll update it.

Sent from Yahoo Mail for iPhone


On Wednesday, May 4, 2022, 11:41 AM, Todd Pfaff <pf...@rh...> wrote:

I first tried this (my usb drive is sdh):

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/systemd-boot-iso/efi-source /dev/sdh


I then plugged that usb drive to my thinstation machine and booted.  I had 
to add the uefi boot entry manually - it wasn't autodetected - not sure if 
that is "normal".  Booting started but failed, I think, because my network 
wasn't configured.  I'm aiming for a static network configuration in this 
case.

I next tried with refind:

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/refind-iso/efi-source /dev/sdh


Same dance, same failure mode - no network configuration.


I have this in my thinstation.conf.buildtime:

NET_HOSTNAME=tc003
NET_IP_ADDRESS=192.168.1.2
NET_GATEWAY=192.168.1.1
NET_USE=LAN
NET_USE_DHCP=false
NET_MASK=255.255.255.0
NET_DNS_SEARCH="mydomain.com"
NET_DNS1=8.8.8.8


What am I missing?  Is there anything else I need to add to either 
build.conf or thinstation.conf.buildtime to be able to efi boot from a usb 
drive with a static network configuration?

Thanks,
Todd


On Wed, 4 May 2022, Todd Pfaff wrote:

> This is all very interesting.  I looked at bt, and flash, and mkgptdrv. Lots 
> of archaeological excavation to do.
>
> What is the current recommended way to write a UEFI bootable USB drive from a 
> command line in the chroot environment?  I don't want to bother with 
> Windows+rufus is I can possibly avoid that.
>
> My guess is that I could either use your /ts/bin/flash script, or I could use 
> a command line similar to what I see in flash, using mkgptdrv or mkmbrdrv. 
> Correct?
>
> In this particular case, since I need to UEFI boot, I think I need mkgptdrv 
> rather than mkmbrdrv.  Correct?
>
> So, looking at your flash script, you have this entry that uses mkgptdrv:
>
> systemd)
>        mkgptdrv -p ESP:2g:boot -p l:0:home -o 
> /build/boot-images/systemd-boot-iso/efi-source /dev/sdb
>
>
> which leads me to believe that I'll need boot-images/systemd-boot-iso, and 
> based on what I see in the build script, this means that I have to add 
> systemd-boot-iso to param bootimages in build.conf.  Correct?
>
> In general, do you recommend just leaving param bootimages empty so that the 
> build script sets it to it's default as it does with this code?
>
> if [ -z "$ts_bootimages" ]; then
>        ts_bootimages="syslinux iso pxe refind-iso systemd-boot-iso grub"
>
>
> Is "systemd-boot-iso" the best option to use for my use case of a UEFI 
> bootable USB drive, or is there something else I should consider that's 
> already baked into the TS6.2 pie (and hopefully won't require me to make too 
> many more educated guesses :).
>
> Thanks,
> Todd
>
>
> On Tue, 3 May 2022, Don Cupp wrote:
>
>>  You can also open the file /ts/bin/bt in a text editor and look at the
>>  code I use for doing different things.
>>
>>  Have a look at
>>
>>  wrap_grub_efi() for some clues.
>> 
>> 
>> 
>> 
>> 
>>
>>  On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp <don...@ya...>
>>  wrote:
>> 
>> 
>> 
>> 
>>
>>  After doing a build, try 
>>  bt net or bt net-efi
>>  to test a pxe boot and possibly an install
>>  afterwards,
>>  bt image-grub to test your install
>> 
>> 
>> 
>> 
>> 
>>
>>  On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via Thinstation-general
>>  <thi...@li...> wrote:
>> 
>> 
>> 
>> 
>>
>>  I use fedora. It’s not the code, just how the distro is handling umount.
>>  You can see me calling it. On Ubuntu, if I don’t use lazy umount, it hangs
>>  the exit.
>> 
>>
>>  Sent from Yahoo Mail for iPhone
>>
>>  On Monday, May 2, 2022, 5:21 PM, Todd Pfaff <pf...@rh...>
>>  wrote:
>>>  It's trivial.  I just run the following command several times after I
>>>  exit
>>>  the setup-chroot shell.  It has become as quick as a !for in my build
>>>  shell.
>>>
>>>  for f in `mount|grep thinstation | awk '{print $3}'`; do echo $f; umount
>>>  $f; done
>>> 
>>>
>>>  So, no big deal, just unexpected.
>>>
>>>  If we're blaming this on the distro, that really suprises me since you're
>>>  basically saying that there are either very few ThinStation users who are
>>>  building on a RHEL/CentOS 7 platform, or all the other TS users who do
>>>  use
>>>  the same distro as me are just suffering in silence.  Maybe, who knows.
>>>  I'd also find it hard to believe this is distro related given that
>>>  setup-chroot is just bash code, and not terribly complex bash code at
>>>  that.  I'm curious now though: on what distro(s) does this all work
>>>  flawlessly?  Maybe I'll spin one of those up just to ease my pain.
>>>
>>>  Todd
>>> 
>>>
>>>  On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>>>
>>>>  Oh the sadness of the various distro peculiarities. How long does it
>>>>  take to try and unmount everything?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>>  On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff
>>>>  <pf...@rh...> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>>  I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>>>>
>>>>  I'm doing builds on a CentOS 7 host.
>>>>
>>>>  Something with setup-chroot is faulty.  When I exit from setup-chroot,
>>>>  it
>>>>  does not unmount things like it's supposed to.  I can clearly see the
>>>>  code
>>>>  in setup-chroot in function do_unmounts() that is supposed to do
>>>>  the unmount, and I can see from where this is called, but it's not doing
>>>>  its job.
>>>>
>>>>  This is then somehow leading to various problems.  We've seen both /dev/
>>>>  and /dev/pts/ go empty while I've been working with ts6.2 recently.
>>>>
>>>>  Todd
>>>> 
>>>>
>>>>  _______________________________________________
>>>>  Thinstation-general mailing list
>>>>  Thi...@li...
>>>>  https://lists.sourceforge.net/lists/listinfo/thinstation-general
>> 
>>> 
>>>> 
>>>>
>>>>  _______________________________________________
>>>>  Thinstation-general mailing list
>>>>  Thi...@li...
>>>>  https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>> 
>>
>>  _______________________________________________
>>  Thinstation-general mailing list
>>  Thi...@li...
>>  https://lists.sourceforge.net/lists/listinfo/thinstation-general
>> 
>> 
>
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Don C. <don...@ya...>]

grub is really the only important output these days. One image will work CD,HD and PXE


Sent from Yahoo Mail for iPhone


On Wednesday, May 4, 2022, 10:13 AM, Todd Pfaff <pf...@rh...> wrote:

This is all very interesting.  I looked at bt, and flash, and mkgptdrv. 
Lots of archaeological excavation to do.

What is the current recommended way to write a UEFI bootable USB drive 
from a command line in the chroot environment?  I don't want to bother 
with Windows+rufus is I can possibly avoid that.

My guess is that I could either use your /ts/bin/flash script, or I could 
use a command line similar to what I see in flash, using mkgptdrv or 
mkmbrdrv.  Correct?

In this particular case, since I need to UEFI boot, I think I need 
mkgptdrv rather than mkmbrdrv.  Correct?

So, looking at your flash script, you have this entry that uses mkgptdrv:

systemd)
        mkgptdrv -p ESP:2g:boot -p l:0:home -o 
/build/boot-images/systemd-boot-iso/efi-source /dev/sdb


which leads me to believe that I'll need boot-images/systemd-boot-iso, 
and based on what I see in the build script, this means that I have to add 
systemd-boot-iso to param bootimages in build.conf.  Correct?

In general, do you recommend just leaving param bootimages empty so that 
the build script sets it to it's default as it does with this code?

if [ -z "$ts_bootimages" ]; then
        ts_bootimages="syslinux iso pxe refind-iso systemd-boot-iso grub"


Is "systemd-boot-iso" the best option to use for my use case of a UEFI 
bootable USB drive, or is there something else I should consider that's 
already baked into the TS6.2 pie (and hopefully won't require me to make 
too many more educated guesses :).

Thanks,
Todd


On Tue, 3 May 2022, Don Cupp wrote:

> You can also open the file /ts/bin/bt in a text editor and look at the code I use for doing different things.
>
> Have a look at
>
> wrap_grub_efi() for some clues.
>
>
>
>
>
>
> On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp <don...@ya...> wrote:
>
>
>
>
>
> After doing a build, try 
> bt net or bt net-efi
> to test a pxe boot and possibly an install
> afterwards,
> bt image-grub to test your install
>
>
>
>
>
>
> On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via Thinstation-general <thi...@li...> wrote:
>
>
>
>
>
> I use fedora. It’s not the code, just how the distro is handling umount. You can see me calling it. On Ubuntu, if I don’t use lazy umount, it hangs the exit.
>
>
> Sent from Yahoo Mail for iPhone
>
> On Monday, May 2, 2022, 5:21 PM, Todd Pfaff <pf...@rh...> wrote:
>> It's trivial.  I just run the following command several times after I exit
>> the setup-chroot shell.  It has become as quick as a !for in my build
>> shell.
>>
>> for f in `mount|grep thinstation | awk '{print $3}'`; do echo $f; umount
>> $f; done
>>
>>
>> So, no big deal, just unexpected.
>>
>> If we're blaming this on the distro, that really suprises me since you're
>> basically saying that there are either very few ThinStation users who are
>> building on a RHEL/CentOS 7 platform, or all the other TS users who do use
>> the same distro as me are just suffering in silence.  Maybe, who knows.
>> I'd also find it hard to believe this is distro related given that
>> setup-chroot is just bash code, and not terribly complex bash code at
>> that.  I'm curious now though: on what distro(s) does this all work
>> flawlessly?  Maybe I'll spin one of those up just to ease my pain.
>>
>> Todd
>>
>>
>> On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>>
>>> Oh the sadness of the various distro peculiarities. How long does it take to try and unmount everything?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff <pf...@rh...> wrote:
>>>
>>>
>>>
>>>
>>>
>>> I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>>>
>>> I'm doing builds on a CentOS 7 host.
>>>
>>> Something with setup-chroot is faulty.  When I exit from setup-chroot, it
>>> does not unmount things like it's supposed to.  I can clearly see the code
>>> in setup-chroot in function do_unmounts() that is supposed to do
>>> the unmount, and I can see from where this is called, but it's not doing
>>> its job.
>>>
>>> This is then somehow leading to various problems.  We've seen both /dev/
>>> and /dev/pts/ go empty while I've been working with ts6.2 recently.
>>>
>>> Todd
>>>
>>>
>>> _______________________________________________
>>> Thinstation-general mailing list
>>> Thi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/thinstation-general
>
>>
>>>
>>>
>>> _______________________________________________
>>> Thinstation-general mailing list
>>> Thi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>
>
> _______________________________________________
> Thinstation-general mailing list
> Thi...@li...
> https://lists.sourceforge.net/lists/listinfo/thinstation-general
>
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Don C. <don...@ya...>]

Glad your digging in.
I should update flash to use the grub image, but you could too. 
/build/boot-images/grub/efi-source
mkgptdrv is the right utility for EFI


Sent from Yahoo Mail for iPhone


On Wednesday, May 4, 2022, 10:13 AM, Todd Pfaff <pf...@rh...> wrote:

This is all very interesting.  I looked at bt, and flash, and mkgptdrv. 
Lots of archaeological excavation to do.

What is the current recommended way to write a UEFI bootable USB drive 
from a command line in the chroot environment?  I don't want to bother 
with Windows+rufus is I can possibly avoid that.

My guess is that I could either use your /ts/bin/flash script, or I could 
use a command line similar to what I see in flash, using mkgptdrv or 
mkmbrdrv.  Correct?

In this particular case, since I need to UEFI boot, I think I need 
mkgptdrv rather than mkmbrdrv.  Correct?

So, looking at your flash script, you have this entry that uses mkgptdrv:

systemd)
        mkgptdrv -p ESP:2g:boot -p l:0:home -o 
/build/boot-images/systemd-boot-iso/efi-source /dev/sdb


which leads me to believe that I'll need boot-images/systemd-boot-iso, 
and based on what I see in the build script, this means that I have to add 
systemd-boot-iso to param bootimages in build.conf.  Correct?

In general, do you recommend just leaving param bootimages empty so that 
the build script sets it to it's default as it does with this code?

if [ -z "$ts_bootimages" ]; then
        ts_bootimages="syslinux iso pxe refind-iso systemd-boot-iso grub"


Is "systemd-boot-iso" the best option to use for my use case of a UEFI 
bootable USB drive, or is there something else I should consider that's 
already baked into the TS6.2 pie (and hopefully won't require me to make 
too many more educated guesses :).

Thanks,
Todd


On Tue, 3 May 2022, Don Cupp wrote:

> You can also open the file /ts/bin/bt in a text editor and look at the code I use for doing different things.
>
> Have a look at
>
> wrap_grub_efi() for some clues.
>
>
>
>
>
>
> On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp <don...@ya...> wrote:
>
>
>
>
>
> After doing a build, try 
> bt net or bt net-efi
> to test a pxe boot and possibly an install
> afterwards,
> bt image-grub to test your install
>
>
>
>
>
>
> On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via Thinstation-general <thi...@li...> wrote:
>
>
>
>
>
> I use fedora. It’s not the code, just how the distro is handling umount. You can see me calling it. On Ubuntu, if I don’t use lazy umount, it hangs the exit.
>
>
> Sent from Yahoo Mail for iPhone
>
> On Monday, May 2, 2022, 5:21 PM, Todd Pfaff <pf...@rh...> wrote:
>> It's trivial.  I just run the following command several times after I exit
>> the setup-chroot shell.  It has become as quick as a !for in my build
>> shell.
>>
>> for f in `mount|grep thinstation | awk '{print $3}'`; do echo $f; umount
>> $f; done
>>
>>
>> So, no big deal, just unexpected.
>>
>> If we're blaming this on the distro, that really suprises me since you're
>> basically saying that there are either very few ThinStation users who are
>> building on a RHEL/CentOS 7 platform, or all the other TS users who do use
>> the same distro as me are just suffering in silence.  Maybe, who knows.
>> I'd also find it hard to believe this is distro related given that
>> setup-chroot is just bash code, and not terribly complex bash code at
>> that.  I'm curious now though: on what distro(s) does this all work
>> flawlessly?  Maybe I'll spin one of those up just to ease my pain.
>>
>> Todd
>>
>>
>> On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>>
>>> Oh the sadness of the various distro peculiarities. How long does it take to try and unmount everything?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff <pf...@rh...> wrote:
>>>
>>>
>>>
>>>
>>>
>>> I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>>>
>>> I'm doing builds on a CentOS 7 host.
>>>
>>> Something with setup-chroot is faulty.  When I exit from setup-chroot, it
>>> does not unmount things like it's supposed to.  I can clearly see the code
>>> in setup-chroot in function do_unmounts() that is supposed to do
>>> the unmount, and I can see from where this is called, but it's not doing
>>> its job.
>>>
>>> This is then somehow leading to various problems.  We've seen both /dev/
>>> and /dev/pts/ go empty while I've been working with ts6.2 recently.
>>>
>>> Todd
>>>
>>>
>>> _______________________________________________
>>> Thinstation-general mailing list
>>> Thi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/thinstation-general
>
>>
>>>
>>>
>>> _______________________________________________
>>> Thinstation-general mailing list
>>> Thi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>
>
> _______________________________________________
> Thinstation-general mailing list
> Thi...@li...
> https://lists.sourceforge.net/lists/listinfo/thinstation-general
>
>

Re: [Thinstation-general] chroot exit leaves mounts mounted

[Todd P. <pf...@rh...>]

I first tried this (my usb drive is sdh):

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/systemd-boot-iso/efi-source /dev/sdh


I then plugged that usb drive to my thinstation machine and booted.  I had 
to add the uefi boot entry manually - it wasn't autodetected - not sure if 
that is "normal".  Booting started but failed, I think, because my network 
wasn't configured.  I'm aiming for a static network configuration in this 
case.

I next tried with refind:

mkgptdrv -p ESP:2g:boot -p l:0:home -o \
/build/boot-images/refind-iso/efi-source /dev/sdh


Same dance, same failure mode - no network configuration.


I have this in my thinstation.conf.buildtime:

NET_HOSTNAME=tc003
NET_IP_ADDRESS=192.168.1.2
NET_GATEWAY=192.168.1.1
NET_USE=LAN
NET_USE_DHCP=false
NET_MASK=255.255.255.0
NET_DNS_SEARCH="mydomain.com"
NET_DNS1=8.8.8.8


What am I missing?  Is there anything else I need to add to either 
build.conf or thinstation.conf.buildtime to be able to efi boot from a usb 
drive with a static network configuration?

Thanks,
Todd


On Wed, 4 May 2022, Todd Pfaff wrote:

> This is all very interesting.  I looked at bt, and flash, and mkgptdrv. Lots 
> of archaeological excavation to do.
>
> What is the current recommended way to write a UEFI bootable USB drive from a 
> command line in the chroot environment?  I don't want to bother with 
> Windows+rufus is I can possibly avoid that.
>
> My guess is that I could either use your /ts/bin/flash script, or I could use 
> a command line similar to what I see in flash, using mkgptdrv or mkmbrdrv. 
> Correct?
>
> In this particular case, since I need to UEFI boot, I think I need mkgptdrv 
> rather than mkmbrdrv.  Correct?
>
> So, looking at your flash script, you have this entry that uses mkgptdrv:
>
> systemd)
>        mkgptdrv -p ESP:2g:boot -p l:0:home -o 
> /build/boot-images/systemd-boot-iso/efi-source /dev/sdb
>
>
> which leads me to believe that I'll need boot-images/systemd-boot-iso, and 
> based on what I see in the build script, this means that I have to add 
> systemd-boot-iso to param bootimages in build.conf.  Correct?
>
> In general, do you recommend just leaving param bootimages empty so that the 
> build script sets it to it's default as it does with this code?
>
> if [ -z "$ts_bootimages" ]; then
>         ts_bootimages="syslinux iso pxe refind-iso systemd-boot-iso grub"
>
>
> Is "systemd-boot-iso" the best option to use for my use case of a UEFI 
> bootable USB drive, or is there something else I should consider that's 
> already baked into the TS6.2 pie (and hopefully won't require me to make too 
> many more educated guesses :).
>
> Thanks,
> Todd
>
>
> On Tue, 3 May 2022, Don Cupp wrote:
>
>>  You can also open the file /ts/bin/bt in a text editor and look at the
>>  code I use for doing different things.
>>
>>  Have a look at
>>
>>  wrap_grub_efi() for some clues.
>> 
>> 
>> 
>> 
>> 
>>
>>  On Monday, May 2, 2022, 06:29:46 PM PDT, Don Cupp <don...@ya...>
>>  wrote:
>> 
>> 
>> 
>> 
>>
>>  After doing a build, try 
>>  bt net or bt net-efi
>>  to test a pxe boot and possibly an install
>>  afterwards,
>>  bt image-grub to test your install
>> 
>> 
>> 
>> 
>> 
>>
>>  On Monday, May 2, 2022, 05:30:02 PM PDT, Don Cupp via Thinstation-general
>>  <thi...@li...> wrote:
>> 
>> 
>> 
>> 
>>
>>  I use fedora. It’s not the code, just how the distro is handling umount.
>>  You can see me calling it. On Ubuntu, if I don’t use lazy umount, it hangs
>>  the exit.
>> 
>>
>>  Sent from Yahoo Mail for iPhone
>>
>>  On Monday, May 2, 2022, 5:21 PM, Todd Pfaff <pf...@rh...>
>>  wrote:
>>>  It's trivial.  I just run the following command several times after I
>>>  exit
>>>  the setup-chroot shell.  It has become as quick as a !for in my build
>>>  shell.
>>>
>>>  for f in `mount|grep thinstation | awk '{print $3}'`; do echo $f; umount
>>>  $f; done
>>> 
>>>
>>>  So, no big deal, just unexpected.
>>>
>>>  If we're blaming this on the distro, that really suprises me since you're
>>>  basically saying that there are either very few ThinStation users who are
>>>  building on a RHEL/CentOS 7 platform, or all the other TS users who do
>>>  use
>>>  the same distro as me are just suffering in silence.  Maybe, who knows.
>>>  I'd also find it hard to believe this is distro related given that
>>>  setup-chroot is just bash code, and not terribly complex bash code at
>>>  that.  I'm curious now though: on what distro(s) does this all work
>>>  flawlessly?  Maybe I'll spin one of those up just to ease my pain.
>>>
>>>  Todd
>>> 
>>>
>>>  On Mon, 2 May 2022, Don Cupp via Thinstation-general wrote:
>>>
>>>>  Oh the sadness of the various distro peculiarities. How long does it
>>>>  take to try and unmount everything?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>>  On Sunday, May 1, 2022, 07:39:07 AM PDT, Todd Pfaff
>>>>  <pf...@rh...> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>>  I'm using thinstation 6.2-Stable, git cloned 2022-04-01.
>>>>
>>>>  I'm doing builds on a CentOS 7 host.
>>>>
>>>>  Something with setup-chroot is faulty.  When I exit from setup-chroot,
>>>>  it
>>>>  does not unmount things like it's supposed to.  I can clearly see the
>>>>  code
>>>>  in setup-chroot in function do_unmounts() that is supposed to do
>>>>  the unmount, and I can see from where this is called, but it's not doing
>>>>  its job.
>>>>
>>>>  This is then somehow leading to various problems.  We've seen both /dev/
>>>>  and /dev/pts/ go empty while I've been working with ts6.2 recently.
>>>>
>>>>  Todd
>>>> 
>>>>
>>>>  _______________________________________________
>>>>  Thinstation-general mailing list
>>>>  Thi...@li...
>>>>  https://lists.sourceforge.net/lists/listinfo/thinstation-general
>> 
>>> 
>>>> 
>>>>
>>>>  _______________________________________________
>>>>  Thinstation-general mailing list
>>>>  Thi...@li...
>>>>  https://lists.sourceforge.net/lists/listinfo/thinstation-general
>>>> 
>>
>>  _______________________________________________
>>  Thinstation-general mailing list
>>  Thi...@li...
>>  https://lists.sourceforge.net/lists/listinfo/thinstation-general
>> 
>> 
>
>